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

[Dmitry Gutov <dmitry@gutov.dev>]

On 26/08/2023 17:31, Stefan Kangas wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
>> Perhaps the maintainers of Emacs should make more effort to increase the
>> benefits of including packages in Emacs,
> 
> What would you propose?
> 
>> as well as make it more
>> frictionless and user-friendly in the sense that many younger
>> programmers are accustomed to.
> 
> Fully agreed.  We are still looking for volunteers to work on getting
> us onto a forge, for example.  Last time we checked, Sourcehut was
> unfortunately not up to scratch: https://todo.sr.ht/~emacs/emacs/1

If it's not, it's not. *shrug*

But if no existing solution agrees with us, that seems to say something 
about us too, right?

> Perhaps things have changed, though?  I guess it wouldn't hurt if
> someone looked into it.

I'm not sure SourceHut is much of an improvement in the way of 
development experience, but at this point any change would likely be a 
positive.

I have to note, though, that their bug tracking solution is either 
non-existent or entirely merged into "mailing lists". Which, no matter 
how well we explain them (and we should try, time permitting) will 
remain alien to a significant fraction of our users.

These are the two main areas in Emacs I would try to address, if I had 
more time and authority:

- Talking to our users (better, more familiar access to bug tracking 
first and foremost, but anything that makes mailing lists friendlier 
would also be a win; GitHub has "Discussions" which are pretty nice, but 
that seems entirely out of reach).

- The initial experience for new users (standard bindings; reworked 
tutorial; reworking of the menu; first install wizards with suggested 
settings presets; etc). I don't have anything new to add here. It's a 
difficult, very poorly defined endeavor without a lot of consensus, so 
even little progress in that area is great.

But the first point in particular (easier user communication) would also 
be important in attracting more third-party developers to contribute 
code to Emacs. Not that it's necessary for all code: I think ELPA is 
perfectly fine for most.

Everything else is secondary.

>> Rather than just "better explaining" it.
> 
> We should be able to work on several things at the same time.

Sure. On the subject of explaining things, I also hope we'll be able to 
reach the point where the leadership doesn't act dismissive toward the 
broader development community and we can finally agree that "What those 
people think" definitely is "a crucial issue" in many situations.