Update contributing to reflect this type of repo better.

CONTRIBUTING.md

@@ -1,20 +1,111 @@
-# Contributing
+# Contribution Guidelines
 
-When contributing to this repository, please first discuss the change you wish to make via issue,
-email, or any other method with the owners of this repository before making a change.
+## Pull requests are always welcome
 
-Please note we have a code of conduct, please follow it in all your interactions with the project.
+We're trying very hard to keep our systems simple, lean and focused. We don't
+want them to be everything for everybody. This means that we might decide
+against incorporating a new request.
 
-## Pull Request Process
+## Create issues...
 
-1. Ensure any install or build dependencies are removed before the end of the layer when doing a
-   build.
-2. Update the README.md with details of changes to the interface, this includes new environment
-   variables, exposed ports, useful file locations and container parameters.
-3. Increase the version numbers in any examples files and the README.md to the new version that this
-   Pull Request would represent. The versioning scheme we use is [SemVer](http://semver.org/).
-4. You may merge the Pull Request in once you have the sign-off of two other developers, or if you
-   do not have permission to do that, you may request the second reviewer to merge it for you.
+Any significant change should be documented as a GitHub issue before anybody
+starts working on it.
+
+### ...but check for existing issues first!
+
+Please take a moment to check that an issue doesn't already exist documenting
+your request. If it does, it never hurts to add a quick "+1" or "I need this
+too". This will help prioritize the most common requests.
+
+## Conventions
+
+Fork the repository and make changes on your fork on a branch:
+
+1. Create the right type of issue (defect, enhancement, test, etc)
+2. Name the branch N-something where N is the number of the issue.
+
+Note that the maintainers work on branches in this repository.
+
+Work hard to ensure your pull request is valid. This includes code quality,
+clear naming, and including unit tests. Please read the Code Of Conduct at the
+bottom of this file.
+
+Pull request descriptions should be as clear as possible and include a reference
+to all the issues that they address. In GitHub, you can reference an issue by
+adding a line to your commit description that follows the format:
+
+`Fixes #N`
+
+where N is the issue number.
+
+## Merge approval
+
+Repository maintainers will review the pull request and make sure it provides
+the appropriate level of code quality & correctness.
+
+## How are decisions made?
+
+Short answer: with pull requests to this repository.
+
+All decisions, big and small, follow the same 3 steps:
+
+1. Open a pull request. Anyone can do this.
+
+2. Discuss the pull request. Anyone can do this.
+
+3. Accept or refuse a pull request. The relevant maintainers do this (see below
+   "Who decides what?")
+
+   1. Accepting pull requests
+
+      1. If the pull request appears to be ready to merge, approve it.
+
+      2. If the pull request has some small problems that need to be changed,
+         make a comment addressing the issues.
+
+      3. If the changes needed to a PR are small, you can add a "LGTM once the
+         following comments are addressed..." this will reduce needless back and
+         forth.
+
+      4. If the PR only needs a few changes before being merged, any MAINTAINER
+         can make a replacement PR that incorporates the existing commits and
+         fixes the problems before a fast track merge.
+
+   2. Closing pull requests
+
+      1. If a PR appears to be abandoned, after having attempted to contact the
+         original contributor, then a replacement PR may be made. Once the
+         replacement PR is made, any contributor may close the original one.
+
+      2. If you are not sure if the pull request implements a good feature or
+         you do not understand the purpose of the PR, ask the contributor to
+         provide more documentation. If the contributor is not able to
+         adequately explain the purpose of the PR, the PR may be closed by any
+         MAINTAINER.
+
+      3. If a MAINTAINER feels that the pull request is sufficiently
+         architecturally flawed, or if the pull request needs significantly more
+         design discussion before being considered, the MAINTAINER should close
+         the pull request with a short explanation of what discussion still
+         needs to be had. It is important not to leave such pull requests open,
+         as this will waste both the MAINTAINER's time and the contributor's
+         time. It is not good to string a contributor on for weeks or months,
+         having them make many changes to a PR that will eventually be rejected.
+
+## Who decides what?
+
+All decisions are pull requests, and the relevant maintainers make decisions by
+accepting or refusing pull requests. Review and acceptance by anyone is denoted
+by adding a comment in the pull request: `LGTM`. However, only currently listed
+`MAINTAINERS` are counted towards the required majority.
+
+The maintainers will be listed in the MAINTAINER file, all these people will be
+in the employment of Bayer.
+
+## I'm a maintainer, should I make pull requests too?
+
+Yes. Nobody should ever push to master directly. All changes should be made
+through a pull request.
 
 ## Code of Conduct