Document when we are okay to dismiss review requests. That's what we
agreed on within the team.

We test code commits on circleci and merges in the OBS
packages. Travis-CI is pretty much unmaintained (e.g. the
gem caches are broken atm and noone cares)

So remove one out of 3 CI systems

- Make the request for contributions more prominent
- Don't bother people with 'alternate ways' of setting up the git commit message template
- Add commit/PR guidelines (partly stolen from https://github.com/rtbkit/rtbkit)
- Add a nice get-Help secion
- split out review section

This should prepare new contributors better for producing changes that we
will actually merge.

Co-authored-by: Henne Vogelsang <hvogel@opensuse.org>

Describe labels in the wiki as a deprecated feature.

This simply is not prepared to be ran with any other uid than
1000 and is not really something that we should point new
contributors to.

Fixes a documentation regression introduced by 81542e1d.

Add commit message guidelines we agreed on some weeks ago

It makes contributing a tiny bit simpler. Anyone contributing code will
run `rake docker:build`, thereby setting up the git commit message
template without having to copy and paste the command. Anyone else
contributing documentation only is still aware of it.

It won't interfere with the global .gitconfig and have potential
side-effects in other projects.

It's a one time setup unlike the previous recommendation. With `cp`, it
needs to be copied again whenever the template changes.

Replaced broken contact link in Contributing.md to fix issue #4442

A bunch of us have talked about what the content of good commit meesages should
look like and came up with this template. Here is how you can make use of it:

cp .gitmessage ~/.gitmessage

Add this to your ~/.gitconfig

[commit]
  template = ~/.gitmessage

Everyboy following this template will help people to understand the changes in
the future. Addtionally it will make it easier for us to use commit messages in
documentation like our Changelog, books or our blog.

Co-authored-by: Manuel Schnitzer <github@mschnitzer.de>
Co-authored-by: Björn Geuken <bgeuken@suse.de>
Co-authored-by: Henne Vogelsang <hvogel@opensuse.org>
Co-authored-by: Moises Deniz Aleman <mdeniz@suse.com>
Co-authored-by: Eduardo Navarro <enavarro@suse.com>

We had two sections of how we review code. This drops the older version.
Though both versions were almost identical.

Brings all the advantages of containers vs. virtual machines. Can
be used as a base for dockerizing for CI/production.

Create a rake task to run git-cop and document it.

Add a *How to write proper commit messages* section to the our
contributing file which include the git-cop current configuration.

We are using `dist` tag but is not in our contributing file.

foreman will start all services/daemons that you need for a
full fledged OBS. There is currently an issue with
thinking sphinx

https://github.com/pat/thinking-sphinx/issues/1049

That's why this is commented out. Nevertheless ts will
be started by clockwork.

MacOS and Windows do not necesarrily run on a case sensitive
filesystem but the backend source needs this.

Remove P0 label from the Contribution readme as it does not exist.

Closes https://github.com/openSUSE/open-build-service/issues/2146

memer -> member

Typo. cofiguration -> configuration

The password for Admin in CONTRIBUTING.md is opensuse and not buildservice.

We can't exec start_test_backend from inside script/ as this
clashes with https://github.com/rails/rails/pull/13528 somehow.

* Rename load_dev_backend to start_development_backend
* drop db:fixtures:obs