Document the standard conventions for maintaining git repos for newcomers about xboxdev HOT 1 CLOSED

Maybe it's just me, but this doesn't feel necessary.

The cited comments I made aren't specific to that project or even XboxDev projects in general - they are standard best practices for any open-source contribution (in most projects / organizations / companies): It's good code when it's impossible to tell that it was written by more than one person.

We also don't have a shared code-style across the XboxDev repos (and in some projects even different files have different styles). This is because we typically inherited code from other projects and only slowly add our own style (usually when problems with the old style arise). Sometimes we might also want to send code back upstream, so sticking to existing styles is important.
So the usual rule is: follow the existing code / commit style on whatever you are working.

So..

• If the previous commits use prefix style: use prefix style.
• If the surrounding code respect 80 column limits: respect it.
• If the surrounding code uses an unusual C style: mimic it.
• For PR sizes / amount of commits / number of diffs: look at existing PRs.

- Basically respect existing rules (implicit or explicit) and mimic the style of all existing work. Complain in an issue if you see something stupid.

Some non-style things are also implied by GitHub and are obvious when looking at our repositories:

• We typically use a fork-based model with feature-branches in forks.
• Maintainers submit their own work via PR.
• Open tasks are listed in GitHub issues.
• Patches are accepted via PRs.

- Generally, this is something most GitHub users will figure out when they open a repository, so there isn't much benefit in documenting it explicitly.

We also aim to have a rather flat hierarchy in XboxDev, so we usually don't have dedicated maintainers for each project. So listing maintainers is not very useful. It shouldn't be important either, as those who have the knowledge will respond to PRs or issues (wether they "own" the code or not).

While I consider CONTRIBUTING.md important for certain projects, it doesn't serve much for most (all?) XboxDev projects. At the moment it would be nearly impossible to write a proper generic CONTRIBUTING.md (other than what I mentioned above, instead of explicit rules).

So I'm skeptical about the benefit of a CONTRIBUTING.md.

At best, we could possibly add a small section to this repository README.md (or CONTRIBUTING.md) to explain our stance on this (if we can decide on a collective stance; the above is just my opinion). We could link a resource for generic best-practices in open-source (most of which will likely align with what I explained above).
We should also mention that we are usually quite strict with contribution quality.
Also we should mention that review can take a while, but that we encourage reviews by non-maintainers (to aid maintainers).

GitHub also supports overlays for certain files. So depending on how they work, we could also try to add a generic CONTRIBUTING.md overlay which links to our generic "we don't have explicit rules" message.

from xboxdev.