[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
impression:
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.
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
https://yhetil.org/emacs-devel/87v8szrfz6.fsf@localhost/
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>
Re: New Package for NonGNU-ELPA: clojure-ts-mode, Ihor Radchenko, 2023/09/01
Re: New Package for NonGNU-ELPA: clojure-ts-mode, Philip Kaludercic, 2023/09/01
Re: New Package for NonGNU-ELPA: clojure-ts-mode, Richard Stallman, 2023/09/01