+
+Quick walktrough:
+
+* Create ticket for new feature
+* Fork the original repository, clone the own repository, add the original repository as upstream
+* Checkout »next-release« branch ```git checkout next-release```
+* Create a new branch on top of that one, e.g. »some-feature« ```git checkout -b some-feature```
+* Make your change
+* You may check if the project is still [REUSE Compliant](https://reuse.software/) by running `docker run -v $(pwd):/code --rm fsfe/reuse /bin/sh -c "cd /code && reuse lint"`
+* Commit changes → push → send merge request ```git add -A; git commit; git push``` MR via GitLab (link shown in console)
+* Feature is reviewed
+ * MR accepted: Reviewer checks out »next-release« branch and cherry-picks the commit ```git checkout next-release; git cherry-pick be4369641; git push```
+ * MR declined: Reviewer add some notes, Developer rebases his branch, adds neccessary changes, force pushes the branch, ask a reviewer to review the changes in the merge request ticket (as Gitlab recognizes them automatically) ```git checkout some-feature; git rebase upstream/next-release``` …[add changes]… ```git add -A, git commit --amend; git push -f```
+
+## New Releases
+
+* If the release is not done for security purposes: create a new issue and freeze next-release branch for at least week.
+* Compare the [»next-release« branch to »master«](https://gitlab.com/mojo42/Jirafeau/compare/master...next-release)
+* Add a list of noteworthy features and bugfixes to the README
+* Fill upgrade procedure in README
+* Change the version, using [semantic versioning](http://semver.org/), in ```settings.php```
+* Merge »next-release« branch to »master«
+* Update the demo page
+* Tag the »master« with the new version
+* Push branch and tag
+* Build & push new docker image
+* Dance a little