...
- Make sure you have an OpenMRS ID--this gives you an account to our issue tracking system.
- Identify the issue you want to work on. (It should have the status "Ready For Work".)
- Click the "Claim Issue" button.
- This will change the status to "In Progress" and mark you as the Assignee, so nobody duplicates your work.
- If you don't see the button, comment on the issue saying so. (This probably means the issue was not "Ready For Work".)
- If you have any questions about the issue, or if it is not clear from the description and comments exactly what is being asked for, then make a comment on the issue asking for clarification.
- If you expect to spend a significant amount of coding time (>= 1 day), then make a comment on the issue describing your planned approach. (In case your plan needs modifications, better to know this early.)
- If the issue is going to introduce non-trivial user interface changes, add a mockup to the issue via More Actions -> Add/Edit UI Mockup. This will typically save you time, by forcing you to design the complete workflow up front. And it allows the issue's reporter and other watchers to make suggestions.
- Design. Write code. (Follow Java Conventions.) Test.
- Make sure you write one or more Unit Tests.
- If you don't know about the @should annotation and then /wiki/spaces/docs/pages/25477775, then please read them.
- Once your code is ready, push it to a branch in your github fork of the repository (see Using Git), open a Pull Request, and comment on the issue with a link to the PR.
- If there is a significant user interface component to your code, attach one or more screenshots to the ticket also.
- Click the "Request Code Review" button.
- This will put the issue in a Code Review (Initial) status
- (You may want to read more about Code Review)
- Comment on the issue saying what you want reviewed.
- If there is only one attached patch, or it's truly obvious which file should be reviewed, you can skip this.
- Eventually, your code will be reviewed. Multiple things can happen at this point:
- The reviewer may may move the issue back to "In Progress" and make comments in the GitHub Pull Request on the changes you need to make before re-submitting.
- The reviewer may merge your changes into the master branch of the source code repository, and request that you make further post-commit changes, also moving the ticket back to "In Progress".
- The reviewer may merge your changes into the master branch of the source code repository, and mark the issue as Closed. (Typically this happens for trivial fixes.)
- During a GitHub Pull Request review for your issue, you will likely receive quite a few email notifications. (You don't necessarily need to reply to each one individually.)
- If the code review didn't raise any issues (or if they were small enough that the reviewer fixed them directly) the issue will be closed.
- If any changes need to be made, then the issue will be put back "In Progress" and the head reviewer will make a comment on the issue pointing to the GitHub pull request comments, that you need to address before resubmitting your code for review again.
- If you have any questions about these comments, make a comment yourself asking for clarification.
- If code changes are necessary, then make those changes, and push them to your github fork. Then re-open your pull request (which will now include your original commit, plus the new one).
- If your code was merged to the master branch of the source code repository, then you'll want to merge that in from upstream, and make your revisions relative to your now-merged code.
- If your code wasn't applied to the source code repository, then you'll need to start working from your prior fork and branch.
- Comment on the issue summarizing the issues you addressed in the new commits.
- Click "Request Code Review" again.
- (Now we're back to step 9.)
...