Skip to content

Latest commit

 

History

History
119 lines (69 loc) · 7.92 KB

get_in_touch.md

File metadata and controls

119 lines (69 loc) · 7.92 KB
Raw

Get in touch

We would love to build a community around FOSSILPOL and there are various ways to get in touch and grow together.

Contact us

We have set up GitHub Discussions as a main hub for communication. Do you have a question? Have you thought about a cool new feature? Let's write us a message. We hope that the Discussions page will serve as a line of communication to the developers as well as between various users.

"It does not work!"

No software is without problems and if you find a nasty bug while using this workflow, please use the Issues page to report it.

Consider the following steps before and when opening a new Issue:

  1. Have you or someone else asked about it at the GitHub Discussions? The "Q&A" section is perfect for that!

  2. Have you checked that similar issues may have been already reported? The issue tracker has a filter function to search for keywords in open Issues. You can narrow down the search using labels🏷️ as filters. See Labels for more information. As a general rule, we don't assign issues to anyone.

To open a new Issue:

  1. Click on the green New issue button in the upper right corner, and select Bug report.

  2. Describe your problem in as much detail as possible. The issue should state what the problem is, what the expected behaviour should be, and, maybe, suggest a solution. Note that you can also attach files (e.g. sample data, R code, etc.) or images to the issue.

  3. Select a suitable label🏷️ from the drop-down menu called Labels.

  4. Click on the green Submit new issue button and wait for a reply.

"Can we add this?"

We also use the Issues page for serious feature requests. If some discussion GitHub Discussions portal leads to a flashed-out feature, you would like to implement, you can submit it as a feature request:

  1. Go to the Issues page

  2. Click on the green New issue button in the upper right corner, and select Feature request.

  3. Describe your feature as detailed as possible. What is the expected behaviour? What packages we should use? Note that you can also attach files or images to the Issue.

  4. Select a suitable label🏷️ from the drop-down menu called Labels.

  5. Click on the green Submit new issue button and wait for a reply.

Project future updates

The FOSSILPOL project is envisioned as software that will undergo updates for further improvement.

We are aware of the functions and features we would like to implement in the future.

See the planned future updates in the project future updates The three stages of request are:

  • "next version" - a feature that will be implemented in the next FOSSILPOL release

  • "future" - a feature that will be probably implemented in one of the future FOSSILPOL releases

  • "in consideration" - the feature might be implemented but it is not a priority

If there is a feature you would like to implement, please first check the Issue Tracker and look if someone already suggested it and up-vote it, if it is already there. Before each version release, we will implement the most up-voted feature.

We aim to regularly update the list.

Contribute

The FOSSILPOL project is envisioned as software that will undergo updates for further improvement.

We appreciate the help 💖 and thank you just for considering contributing to FOSSILPOL.

To make sure that we maintain the highest quality of code, we do have to adhere to some strict guidelines though. Please read through this document to help you get up and running.

If you would like to report a bug, suggest enhancements, or request a new feature, jump to the Issues section.

Git + GitHub

We use the Git version control system to manage the developments in the repository hosted on GitHub. If you are new to Git or GitHub, please read through the GitHub Bootcamp to get up to speed.

If you are already familiar with Git and GitHub, please read Submitting Pull Requests.

Coding Style Guidelines

While we do have our style in coding and haven't followed any standards available on the web, we do maintain some uniformity.

If we missed mentioning a particular case, you should always follow the below procedure:

Submitting Pull Requests

All changes to FOSSILPOL must be in the form of a pull request (also known as a PR). If you are unfamiliar with pull requests, please read this.

Here is the recommended process:

  1. Fork the repo so that you can make your changes without affecting the original project until you are ready to merge them. Check out the Guide to forking

  2. Check out the branch (named the next version; if there is one).

  3. Commit your updates once you are happy with them. See contributing guide for commit messages.

  4. When you are finished with the changes, create a PR

    • Click the "Ready for review" so that we can review your PR. This template helps reviewers understand your changes as well as the purpose of your pull request.
    • Don't forget to link PR to the Issue if you are solving one.
    • Enable the checkbox to allow maintainer edits so that the branch can be updated for a merge. Once you submit your PR, a HOPE team member will review your proposal. We may ask questions or request additional information.
    • We may ask for changes to be made before a PR can be merged, either using suggested changes or pull request comments. You can apply suggested changes directly through the user interface (UI). You can make any other changes in your fork, and then commit them to your branch. As you update your PR and apply changes, mark each conversation as resolved
    • If you run into any merge issues, check out this git tutorial to help you resolve merge conflicts and other issues.

Before submitting a pull request, please make sure you follow all the guidelines below while working on your changes:

  • Each pull request should try to accomplish one general task.
  • All work should be done on a branch with a descriptive name relating to the general task (eg. fix_bug_x or add_feature_y). Each commit should accomplish one small sub-task and should be explainable in a sentence or two.
  • Each commit should have a descriptive commit message.
  • You should make sure your code passes all tests before committing.