Document contribution workflow

CONTRIBUTING.md

@@ -0,0 +1,40 @@
+# Contributing to VINE
+
+We follow a simplified [Gitflow] methodology. The _main_ branch reflects
+production code and is automatically deployed via Github Actions. We never
+push commits directly to _main_ and don't point pull requests there unless
+it's a very urgent hotfix.
+
+The _develop_ branch should be the target for all your pull requests. The
+code is automatically deployed to the staging environment for testing.
+
+## Creating a pull request
+
+Name your branch `feature/...` to describe the thing you are developing.
+For example, the branch `feature/multi-merchant` added the functionality
+to connect multiple merchants to one voucher set.
+
+In rare cases, we may need to bypass the _develop_ branch and fix the _main_
+branch. Then name your branch `hotfix/...` and include only the minimal
+changes necessary to fix the bug.
+
+In any case, commit frequently to your branch to create a Git history that's
+as easy to read like a book, page by page. Commit messages should explain the
+_why_ of your code change. The _what_ can usually be observed in the diff.
+
+Before you publish your pull request for review, make sure it's based on the
+latest commit of the _develop_ branch for features or on the latest commit of
+the _main_ branch for hotfixes. Use `git rebase` before publishing your code.
+
+## The release process
+
+New pull requests will be reviewed and merged by one of our team members.
+Manual testing is done on the staging server before we merge to _main_ and
+release new code to production.
+
+When merging to _main_ we decide about the version number of the next release.
+We follow [semantic versioning]. Patches receive a new version without release
+notes. And new features are marked as minor change with release notes.
+
+[Gitflow]: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
+[semantic versioning]: https://semver.org/

README.md

@@ -12,7 +12,10 @@ VINE is a voucher management platform owned & managed by the Open Food Foundatio
 
 ## Developer initial setup
 
-To run the locally on your development environment, follow these steps:
+Please read our [Contributing Guide](CONTRIBUTING.md) before creating a
+pull request.
+
+Then follow these steps for your local development environment:
 
 1. Clone this repository to your local machine.
 2. Install the required dependencies using [`npm install`]
@@ -23,7 +26,7 @@ To run the locally on your development environment, follow these steps:
 7. Run the development server using the command [`npm run dev`]
 
 
-All pushes to develop and master branches will run the app through GitHub Actions. If the tests pass, the action will send a webhook request to the chosen deployment platform, where it will be deployed.
+All pushes to develop and main branches will run the app through GitHub Actions. If the tests pass, the action will send a webhook request to the chosen deployment platform, where it will be deployed.
 
 
 ### How to build the application and leverage assets
@@ -51,7 +54,7 @@ To run tests locally, do the following:
 
 ### Deployment policies
 
-All pushes to develop and master branches will run the app through GitHub Actions. If the tests pass, the system will deploy the app using the configured deployment tool.
+All pushes to develop and main branches will run the app through GitHub Actions. If the tests pass, the system will deploy the app using the configured deployment tool.
 
 ## API documentation