Being able to make a small change is good when every thing is well defined small parts. You can change the part you want and then use everything else as per normal. If everything is so tightly integrated that you end up having to maintain a fork of a large project, it doesn't work out so well.
I don't know which is true for this particular case, but I'd hazard a guess that it is a much bigger task than it needs to be.
I have seen Gnome devs talk of removing features because people were using them the wrong way. Not that people weren't using the features at all, just not for the purpose for which they were written. Experiences like that make me think that pull requests wouldn't get you very far either.
As a gatekeeper in an unrelated small project, I understand gatekeepers being selective. You have a vision, design standards, quality standards. Drive-by PRs that add "just this one thing I need" features is how your well-designed, cohesive project becomes a kitchen sink of shit.
> You have a vision, design standards, quality standards.
Unless, of course, all of those are shit, so a more design-competent person can drive by with an improvement, which will be rejected because it's too shiny
You're not, that depends entirely on the assessment of the relative approaches and whom you care more about, users or a subset of designers closest to the gates.
But that's beside the point, the point was the criticism of the "send a PR" even though that resolves nothing due to the mismatch.
While I prefer tiling windows manager, GNOME’s approach is sensible. Restrain your features to a restricted default and allow users to extend it if they want to. The code is open and well organized as far as I can see. So it’s very easy to see where to extend from.
Gnome devs not withstanding, you have access to the source to change it if you want or put up a PR?