Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[Ihor Radchenko]

Richard Stallman <rms@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-PJ@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>