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 prepended 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 100-FooBar.
4. D makes her/his changes. Each commit on this branch must have a meaningful (English) commit message and refer to the issue number in the syntax #N, where N is the number of the issue. There are many useful hints on what constitutes a good and meaningful commit message, e.g., here or here. In essence, a good commit message is a summary of the changes made (what) and the rationale for the change (why).
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 pull request, provides a summary of the changes made in the description of the pull request, and assigns a suitable reviewer, R, to the pull request. D links the original issue to this pull request. D also puts comments into the form of the pull request explaining how she/he has verified the changes (e.g., created a unit test, ran a system test, did a manual test).
7. Our CI runs automatic checks and adds them to the review discussion. Some of the checks provides a suggestion how they should be resolved. D triggers those suggestion or otherwise addresses them and when done, resolves them.
8. When all automated review comments have been addressed and resolved, 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.
9. 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 (where the comment must explain why D believes the review comment to be addressed sufficiently).
10. 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.
11. 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 pull 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.