+
+Quick walkthrough:
+
+* 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
+
+* Fetch weblate and rebase and import translations
+* 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/pcanterino/Jirafeau/compare/master...next-release)
+* Add a list of noteworthy features and bugfixes to `CHANGELOG.md`
+* Add eventual upgrade procedure to `CHANGELOG.md`. Make sure to list all new configuration items.
+* Build and test docker image
+* Change the version, using [semantic versioning](http://semver.org/), in ```settings.php```
+* Merge Β»next-releaseΒ« branch to Β»masterΒ«
+* Tag the Β»masterΒ« with the new version
+* Push branch and tag
+* Push new docker image
+* Update the demo page
+* Dance a little