Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Sun, 27 Aug 2023 00:41:35 +0300
> Cc: danny@dfreeman.email, stefankangas@gmail.com, emacs-devel@gnu.org,
>  manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 26/08/2023 23:14, Philip Kaludercic wrote:
> > I only mention this, because I don't agree with the premise that this
> > boils down to "mailing-list" or "web-interface".  While it is true that
> > a lot of people are uncertain and afraid of sending a message to a
> > mailing list, this fear is unreasonable and worth dispelling.
> 
> It's not so much a matter of being afraid. We're not squirrels. Using 
> Debbugs is an exercise in frustration because a random user won't know 
> how to respond to an existing issue (finding them is clunky, but 
> doable), how to respond to a particular comment without having been 
> subscribed to the mailing list previously (there's no way to do that, 
> and it's a common feature in most bug trackers and discussion 
> platforms), how to properly respond to an email from a bug tracker that 
> does arrive in your inbox, how to avoid dropping people from 
> conversations, how to avoid being dropped themselves at some point. And 
> so on.
> 
> Anybody who doesn't have enough patience to google how to do the most 
> basic things, we just don't see.
> 
> Another thing we're missing, is an easy-to-access list of most recent 
> conversations and bug reports. Which for many projects partially serves 
> as an invitation to join in, too (as long as it's easy to do from there).
> 
> > I think there is a reasonable point to be made that the CA prevents
> > certain valuable contributions from entering Emacs/GNU ELPA.  IANAL, so
> > I don't know if a sign-off procedure would be a sufficient alternative?
> > But if I am a bit cynical, I cannot deny that having a CA-system can
> > also help filtering out a lot of noise and low-quality code (I'd claim
> > that the average quality of a ELPA package is higher than that of
> > packages on MELPA...).
> 
> Virtually any barrier would increase the average quality of the code. If 
> we required everybody to do fifty squats, film that, and attach together 
> with the first patch submission, that would also increase the average 
> quality, filtering out the less motivated.
> 
> I'm not sure the cost-benefit ratio is good, though.

IMNSHO, the above is an extremely optimistic and naïve view of the
actual state of matters.  Significantly, it emphasizes the advantages
of the proposed changes/alternatives and consistently and completely
ignores the disadvantages (which are known and were described and
discussed many times).

But the important part is what was said many times in this and other
similar discussions: those who want these deep changes are invited to
step up and become Emacs (co)-maintainers, and then make the changes
and actually use them for Emacs development, instead of telling others
how to do their jobs.  It is at least unfair to expect us to do our
job well, and then tell us how to do it and what tools to use for it.
And that is even before we recall that those alternative tools are
either semi-broken or lack important features (or both) that the
existing "obsolete" tools offer us basically for zero cost.  And none
of the alternatives withstood the test of time and/or the magnitude of
the project.