Project wide information on how to contribute and collaborate.
Here are some guidelines to using the Github issues for communicating and managing tasks.
If you are new to Github issues. Please take some time and read this fast and gentle guide to Mastering github issues:
We use Labels to categorize issues created. For the project, we have 2 dimensions to which an issue should be tagged on. Type of Issues: Feature or Bug
Severity: High or Low
Barring special cases, when submitting an issue make sure it is tagged with one of the following labels:
Feature: This if for issues that adds new functionality to the application. Use feature also for issues that enhances or modify existing behaviour.
Bug: Use the bug tag when reporting anomaly in the system.
When submitting an issue, also ensure to add the severity label. You have one of the following labels to do just that:
High: There is fire on the mountain! The wife is going into labour! You get the jist? It should be done as soon as possible!
Low: Really good to have...but It can wait.
When creating a feature request, try to be detailed as possible. Understand that for the feature being requested to be built in the exact manner you want, the details need to be specified. Being explicit, even over the tiniest details is prefered. Avoid assumptions.
When creating bug reports, please ensure to include the reproduction steps. “it does not work” is not good enough. We would need more than that for us to be able to identify the problem and fix it.
Couple of important things to always include in bug reports:
-
The exact steps that led to the issue. What you clicked, what you were expecting, what you got instead.
-
If you can consistently reproduce the issue. That is if the issue happens all the time, or if it happens sometimes in a random, unpredictable way. Issues that happens all the time are easier to solve.
-
Screenshot of the error page when possible.
--