RFC Pull Request Guidelines

#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.

New features should also have an issue to propose and explain the feature, so that we are aware of what's coming. It also creates a place to "work" the feature before useless effort is expended.

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.

Start by reading issue #18656 and the discussion here to understand the pull-request problems being addressed. Compare the suggestions about scope, related issues, and module changes, then determine whether the project has an existing contributor-guidelines location. Done means an agreed, maintainable set of pull-request guidelines is documented.