This is of no value for people who want to contribute. It's "just" a way
we work together as team. Also mention the good-first-issue label

Makes it easier for new contributors to find things to do.

Co-authored-by: Dany Marcoux <dmarcoux@posteo.de>

This is recommended markdown format. Also removes the first headline, it's
superflous with the filename.

If we tell them why we want them to do something they have the chance to
understand why it's important to us.

Also includes some wording changes and markdown formatting to make things a bit
more clear.

We shouldn't overwhelm people with rules, let's stick to what we really
need and leave the nitpicks to some other place.

Better tell people what we want in the place where it matters, than
in some page somewhere.

Nothing is ever perfect. It's also not perfection we strive for but good
collaboration.

This also fixes the TOC link.

When we updated this section we forgot to change the link.

Co-authored-by: Dany Marcoux <dmarcoux@suse.com>

.. as its covered in https://en.opensuse.org/SDB:Docker already.

permissions for user

This reverts commit 0e1f7690.

This reverts commit 90eba0de.

Following a discussion with srinidhi/@srinidhibs on IRC, I realized that
we didn't document this and not fulfilling this requirement causes
issues when trying to run feature specs.

The other one doesn't exist anymore.

Emphesize more that the backend won't run on MacOS and Windows.

Following our retrospective discussions, we agreed to have a pull
request template to promote good practices in pull requests we create
and receive. This is for us, but also for our contributors.

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.