[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clo

From: Ihor Radchenko
Subject: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode)
Date: Sun, 03 Sep 2023 08:32:16 +0000

Richard Stallman <rms@gnu.org> writes:

>   > Exactly.  TBH I still have to assemble courage to post here.  All these
>   > top dogs with their super-dry yet elaborate communication style are
>   > surely, um, intimidating.
> That is not a good thing.  Maybe we can continue on the path of the Kind
> Communication Guidelines (https://gnu.org/philosophy/kind-communication.html)
> to make emacs-devel less intimidating.
> Would you like to start accumulating a list of examples that do,
> or did in the past, feel intimidating to you?  We could learn ommething
> from that.

I can share some subjective experience:

Sometimes, the replies to proposals/reports have a tone that is
seemingly rejecting compromises. There are two aspects to this

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

   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

   Though some kind of FAQ might be useful to lead people to more
   detailed explanations. Pointing "this has been discussed many times
   in the past" feels intimidating as it is not always clear how to find
   the previous conclusions of "discussed many times" in the large
   volume of emacs-devel archives.

2. The previous point feels even worse when there is miscommunication
   and the rigid "no" (or other assertions) is coming from
   misunderstanding each other.

   For example, https://yhetil.org/emacs-devel/83czffzo73.fsf@gnu.org/
   thread was quite hard to manage, partially because of such
   mis-communication. It took a few, sometimes heated, exchanges until
   we figured out the misunderstanding in

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. A recent example is
   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65451#26, where I
   somehow _felt_ like my proposal cannot be accepted at all. Which was
   not true, as an alternative implementation of the same feature was
   more as rigidly rejected. Maybe it is just me, but it was quite
   emotionally difficult to keep the discussion going and constructive.

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>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]