Clone this wiki locally
- there are 3 important kind of branches
masteralways contains the latest stable and generally accepted state in the form of specific merge commits from the
devbranch contains the latest development changes, that are verified to work by unit tests and 2 reviewers (see Commit-Policy)
- specific feature branches, created by the developers
Acceptance criteria for
dev contains the latest changes that are considered to be working by their creators and at least 2 reviewers. To continually ensure good quality of code some requirements must be met for a commit to be allowed into
- all commits belong to a github Issue
- the Issue contains an understandable description of the problem that enables reproduction
- the Issue contains an understandable and assessable description of the solution
- all code changes 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 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.
All changes to these rules must be accepted in a Stammtisch Meeting.
This is a suggestion, but following these suggestions is considered to be most effective by the maintainers to get your changes into the
- 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.
- Document the chosen solution within the Issue and explain why this solution was chosen.
- 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 thereby ensuring it can be referenced
accordingly. Develop and discuss with other developers according to the situation. For bigger
changes consider breaking them down into smaller steps, which increases the chance of your
changes to be applied to the
- Write unit tests for your code changes, preferably while writing the actual code.
- Find 2 team members 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 appear to be fulfilled, inform the maintainer (an @name in a comment might be sufficient).
- After applying any changes that may be requested by the maintainer, you might still have to make sure, that he really commits your changes to the dev branch.
Acceptance criteria for
dev branch may be merged into master whenever the Stammtisch decides its current state warrants doing so.