Change Management

Branching model

• there are 3 important kind of branches
• master always contains the latest stable and generally accepted state in the form of specific merge commits from the dev branch
• the dev branch contains the latest development changes, that are verified to work by unittests and 2 reviewers (see Commit-Policy)
• specific feature branches, created by the developers

Acceptance criteria for dev branch

dev is the most important branch at the moment, because it contains the newest changes that are considered working by their creators, 2 reviewers and maybe additionally maintainers. To keep up the good quality of code there is crutial and therefore some requirements must be met for a commit to be allowed into dev:

• all commits belong to a github Issue
• the Issue contains an understandable and reproducable description of the problem
• the Issue contains an understandable and assessable description of the solution
• actual code changes, that are well documented, formatted according to (not yet publicly available) coding standards and high quality in other standards that might be formalized later on
• unit tests with 100% statement coverage for the code changes
• if necessary and possible: adapted documentation and integration tests
• 2 DFE team members, who acknowledge the issue's success.

These requirements can be overruled only by 100% acceptance of all developers, reviewers and both maintainers for a single Issue. Changes to these rules in general must be accepted in a Stammtisch Meeting.

Development process

This is a suggestion, but following these suggestions is considered to be most effective by the maintainers to get your changes into the dev branch.

• Create the issue in the Github tracker
• Discuss the problem (-description) with the mailing list, Stammtisch or other developers to make sure, it's well enough described and understood.
• Also discuss solution suggestions and their implications.
• Write down the actually applied solution into the Issue and also describe why you chose this solution over others.
• Create a feature branch (or fork, if you don't have commit rights on the DFE repository) for your Issue and don't forget to name your Issue number (e.g. #123) in your commit that it can be referenced accordingly. Develop your stuff and discuss with other developers according to the situation. For bigger changes think about breaking them down into smaller steps, which also increases the chance of your changes to be applied to the dev branch.
• Write unittests for your code changes, preferably while writing the actual code.
• Find 2 people to acknowledge your success. The smart developer will look for these guys early on in the development process and keep them interested in the topic.
• When all requirements seem to be fulfilled, then inform the maintainer (an @name in a comment might be sufficient).
• After changing your stuff according to the feedback of the maintainer, you might still have to make sure, that he really commits your changes to the dev branch.