-
Notifications
You must be signed in to change notification settings - Fork 47
Contributor guidelines for developers
Tech team calls occur weekly on Monday at 10:00 pm EST. We use Skype for group calls. Make sure you have the latest version of Skype installed. Use the link below to join the call. https://join.skype.com/C6hKycJn0IOn/
Once you choose an open issue to work, add yourself as an assignee. Create a branch for that issue. Name that branch as "#IssueNo-short-three-word-description-of-the-issue". If you are working on multiple issues in a single branch you can name all the issue numbers in the Good branch names:
- #200-language-support-for-odiya
- #108-#109-#112-added-activity-for-patient-registration
Bad branch names:
- julies-branch
Commit frequently to your branch! Name your commits something meaningful! Good commit descriptions:
- Fix for issue #425
- Created sync activity
Bad commit descriptions:
- Minor fixes
- John's commits
Working on an issue goes through the following steps in the development life-cycle:
When an issue is in the backlog, implementers or projects who are interested in this feature can comment on it, vote on it, assign a priority level to it. Please be as specific as possible when describing or commenting on the issue. More information is always good! Also there are no such thing as dumb comments, speak up with your feedback!
When an issue has been chosen for a milestone or a sprint the assigned developer will reach out to the person who created the issue or any of the people who have commented on it to gather the background requirements.
When you're working on an issue, please move it to In progress. This will let the sprint manager know that you have started working on the issue.
If at any point of time you have questions about the issue, move it to Review/QnA. Otherwise, if you are done with the issue you can move it to Review so that someone can review your code and make sure its up to scratch and conforms to our best practices
Every issue undergoes thorough verification testing. Verification testing = your end product does exactly what it should do. In this phase we test for user need fit (did it meet the user's need), usability, functionality (did pressing button A have the desired action), bugs and potential sources of error in the code. If any bugs are found, the issue is returned to the "In Progress" tab. The results of the test are included in the issue as a comment.
After testing is complete, the issue is moved to closed. You should create a pull request at this point to merge your code into the master branch or release branch.