RFC Pull Request Guidelines

[wpferguson]

#18656 exposed some issues with the way that we do Pull Requests, Those issues resulted in some "heated" discussions, bent feelings and lots of frustration. It also didn't reflect well on us as a community.

So, in order to try and prevent another problem/experience like this maybe we need to have some guidelines for pull requests.

---

Some Suggestions

Limited Scope

How many specific issues should we fix in one PR? #18656 started out as UI improvements but grew and grew until it was "impossible to review and far too large a project for one pr" in the words of one dev.

Related Issue

Require a related issue? This is important when we are fixing something that is "broke". The issue should identify what's 'broke" and how to reproduce. That way we can test the PR to make sure "broke" is fixed. This issue also allows us to make sure that "broke" is broke.

How Much Change is Too Much

This kind of goes hand in hand with Limited Scope but at what point do we decide that module changes to "fix" a module result in enough change to warrant a new module, especially if the existing module isn't broken.

[TurboGit]

We probably want to rewrite part of the documentation here https://github.com/darktable-org/darktable/wiki/Developer's-guide with some of the idea here.

[paperdigits]

I have previously requested some sort of mock up and description for UI changes. That was shouted down loudly, but I'm here bringing it up again.

Had the person on the PR in question provided some mock ups and ideas for solving a problem before proposing a PR, a lot of stuff could've been hashed out before code was written and time was wasted.