TL;DR There is a difference between rigid rules and guidelines. I understand the pushback against rigid rules, but clearly documented guidelines are useful for contributors and have no drawback that I can think of.
Let me offer a bit of perspective as someone who is at the margin and is trying to contribute with ideas and the occasional bit of code while observing the dynamics of this community.
- When I tried to discuss some UI aspects here on Pixls, I was told (among other things and in varying degrees of kindness) that there is no point in discussing something if one does not have already implemented the code to back it up.
- I have proposed a couple of features with a working (proof of concept) implementation around shortcuts here on Pixls, and in both cases I was told that it would be better to iterate on it in a PR instead of doing it on Pixls.
- Following that, I have created a PR for a UI change after introducing it here on Pixls and receiving positive feedback. I was told that I should have created an issue on github before preparing the PR. The PR didn’t receive any push back, but it didn’t get any attention either.
What I make of this is that (1) different devs have different standards and expectations, (2) their communications here and on github are not coordinated, and (3) the kind of response that you get from the first dev that stumbles on your proposal/idea/FR/PR by and large sets the tone moving forward.
I think that most of the disagreement in this thread arises from the fact that some folks are talking about guidelines (the term used in the OP), whereas others about strict rules.
A set of strict rules would not be good, as you don’t want to have too much red tape in a project that feeds on freedom and spontaneity, but the core dev team should be able to agree on a set of broad guidelines to help willing contributors get some clarity and find their way around. And if hard rules exist, such as “no algo changes that break modules’ backwards compatibility”, then they should be prominently stated.
@hannoschwalm Guidelines (not hard rules) may not solve any of your problems, but they would make things easier for aspiring contributors (and, I would argue, on average make things easier for the core devs).
@wpferguson and @paperdigits are right in advocating for some more clarity. It cannot hurt to have a “golden path” documented prominently (and possibly enforced at least verbally in the templates for FR and PR on github).
I for one would definitely prefer not to have to second guess what is the right next step to take to get the devs attention without pissing them off or wasting their time.