Richard Stallman <r...@gnu.org> writes: > > 1. Maintainers often say "no" to certain things (like code refactoring > > that does not lead to any clear improvement) because they know from > > their extensive experience that some ideas are "non-starters". > > However, they do not elaborate much why one or another thing is not > > acceptable. > > > Not elaborating is actually perfectly understandable - it would be > > annoying to repeat the same thing many times and would also waste the > > maintainer's valuable time that could be spent for something more > > productive. > > I think I can understand why this feels painful -- but what concretely could > we ask the maintainers to do which would be better overall?
I have two possibilities in mind: 1. For the common questions/misconceptions that keep appearing, there might be a dedicated FAQ answer that can be quickly linked to. For example, in Org mode we often point new contributors who did not follow our patch conventions to https://orgmode.org/worg/org-contribute.html#first-patch or quickly link to an explanation why ancient Emacs versions are not supported: https://orgmode.org/worg/org-maintenance.html#emacs-compatibility or explain our general maintenance principles in https://bzg.fr/en/the-software-maintainers-pledge/ 2. Do not treat all the users the same: - The users submitting bug report/email the very first time (or generally having just a handful of emails on the list) may be greeted with more welcoming style, with detailed explanations. Especially if such a user is proposing something that has to be rejected. - Users that do not seem to be familiar with specialized Elisp or Emacs terminology may require different reply style compared to devs, especially Elisp devs. > When you say "maintainers", do you mean the Emacs maintainers > (currently Eli, Stefan and I)? Or does it mean the people who develop > whichever file you're proposing a change to? I meant more than you three - whoever is replying to a proposal/suggestion with very confident tone implying good knowledge of the topic. Such people are usually Emacs maintainers, built-in Elisp library maintainers, and sometimes just random people who happen to sound knowledgeable. (I know that such random people often have nothing to do with Emacs team, but there is no easy way to distinguish them from real maintainers when reading long threads; for example see https://yhetil.org/emacs-devel/e1qxkgm-0005is...@fencepost.gnu.org/) > > 3. Sometimes, replies to certain feature request feel like a show > > stopper not because the feature itself is not acceptable, but because > > the specific implementation is not deemed good. > > Would it be halp if the people who respond make an effort to > distinguish between their comment about the the behavior tat could be > changed, and their comments about the specific method of implementing > that change? We might be able to get better at that, since I expect > everyone will agree it is good to do that if one can. It would indeed help. Another possibility is following the style often used in technical conferences: (1) Always acknowledge what is good about presentation/idea; (2) Go ahead with questions/critique. That first part is often very trivial - it will not directly lead to improving the presented work/idea, but it really helps to not sound like "I only have questions/critique about your work. Nothing else, nothing good.". -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
