DevelopmentWorkflow

Development Workflow

When any change is to be made (be they corrections, improvements, or enhancements), we follow the following development steps:

1. An issue is created for each requested change with a meaningful title and description.
2. A developer, D, is assigned to the issue either by the person who submitted the issue, by self selection, or by any other team member.
3. D creates a new branch forking - in general - from the master branch. The name of the branch must reflect its purpose. The number of the issue must be appended to the name of the branch separated by a dash. For instance, if the branch was named FooBar implementing the change request #100, the name should be FooBar-100.
4. D makes her/his changes. Each commit on this branch must have a meaningful description and refer to the issue number in the syntax #N, where N is the number of the issue.
5. When D thinks she/he is ready, D checks whether D's changes conform to our coding-style guides and then runs all unit and play-mode tests and verifies that none of these reports any problem).
6. D creates a merge request and assigns a suitable reviewer, R, to the merge request. D links the original issue to this merge request. D puts comments into the form of the merge request explaining how she/he has verified the changes (e.g., created a unit test, ran a system test).
7. R reviews the changes carefully and makes suggestions in the GitHub code review wherever appropriate. R bases her/his judgment also on our review checklist. Ideally, R runs SEE, too, and checks whether the changes meet the requirements and have not broken existing features.
8. D replies to the suggestions made by R in the GitHub code review and implements and commits them in her/his branch. D replies to the comments in the GitHub review and marks each of them as resolved.
9. When R goes once more through all changes after the review and the replies by D. If R thinks the changes address the issue, she/he approves them at GitHub.
10. Either Rainer or Marcel merge the pull request into the master. The closing comment should contain the phrase "This closes #N" where N is the number of the issue, so that the issue is automatically closed in case the pull request was connected to the issue. Automated closing works only when the issue was linked to the merge request and the comment refers to the issue with suitable keywords ("closes" is just one of them). If the issue is not closed automatically, Rainer or Marcel close the issue manually. If the issue was not completely implemented as originally described, the differences are explained in the comment.