Re: [nongnu] main 74116339a8 2/3: * elpa-packages (anzu): New package

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> I think this might be worth discussing.  The impression I get is that a
> lot of packages/libraries are not being used because they are better,

Agreed.

> The "danger" is that MELPA might give the wrong impression of
> popularity:

Yes, I see the same problems and hope that we will eventually be able to
do better on (Non-)GNU ELPA (and I hope MELPA will, too)!  For example,
we could show download count in the last 12 months in addition to the
total downloads.  If we could add a "?major-version=28.1" to the URL or
somesuch, we could even start counting downloads per major version.
(Though I'm not sure if there are any privacy implications, or if it
should be opt-in or opt-out.)

I also think we should have a "rating" system in place, which should
also somehow include information on which version/date the user rated
the package in.

> Do we want to collect as many packages as possible, even if the
> implementations and practices are sub-optimal, are displaced by
> alternative implementations in Emacs or ELPA, etc. or should we try to
> restrict the packages to popular, "good citizens" of the Emacs package
> space, in an effort to raise the standards and clean up "obsolete" and
> "redundant" packages.  It is probably clear that I have an inclination
> towards the latter position: Going forward it seems preferable to have
> as many useful and idiomatic packages available directly via the ELPAs,
> without burdening newcomers with duplicate functionalities.  My
> motivation in contributing to NonGNU ELPA is to further this goal.

I basically agree.  I won't be adding redundant or novelty packages
myself -- unless I do it by mistake! -- but there is also some balance:
I don't want to impose my opinions on everyone else.

So when it comes to "evil-*" packages, I feel like I did my part by
adding the 10-15 most downloaded ones on MELPA.  I don't use evil, so I
have no other criteria to go by, really.

But when it comes to packages I do use, like ace-jump, I noticed that it
had been superseded by avy.  So I added this to my private NGE notes:

    *** Packages not to add
    - ace-jump: seems superseded by avy (in GNU ELPA)

I'm not sure if we should have a public record of packages we decide
*not* to add.  If we did, one place to put it would be just directly
`nongnu/elpa-packages` itself, in the regular alphabetical order, which
is a place you're less likely to forget looking in.

>  It seems to me that MELPA leans
> towards completeness, adding anything from serious packages to fun and
> jokes.

I think we should take the middle ground: let's not *only* add the most
technically sound and excellent packages, because you'll end up with a
lot of stuff that is actually used by people that won't make the cut.

But let's also steer clear of the obvious low
effort/patch/bad/novelty/obsolete/unmaintained packages.

I *hope* that in general you will find that my additions have been
balanced, but please point out if you see any examples (such as anzu)
that you think we could discuss.

>  While I do understand the motivation/advantages, it appears to
> fuel the "there is a package for that" mentality (parallel to Apple's
> "there is an app for that"-slogan), that implies to download a package
> for every little change, instead of writing or even copying some Elisp.
[snip]
> (From what I remember you were intending to present a talk on a related
> topic at EmacsConf last year, right?)

Correct.  Unfortunately, I had two consecutive colds and couldn't make
it.  But as you can imagine, I strongly agree with you.  ;-)

I am not against any efforts in this direction, of course, and I would
welcome any kind of initiative to do "community outreach" here.
However, I think the place when we can really start doing such work is
when people start coming to *us* to ask to be added, and not the other
way around.  This will happen eventually, I think, but we have a bit of
an up-hill battle to get the first critical mass (getting Emacs 28, 29,
30 out the door will help of course).