Re: [ELPA] New package: activities

[JD Smith <jdtsmith@gmail.com>]

> On Jan 29, 2024, at 7:08 PM, Chris Van Dusen <cavandusen@gmail.com> wrote:
> 
>> On Jan 29, 2024, at 15:49, JD Smith <jdtsmith@gmail.com> wrote:
>> 
>> PS: I personally feel that by the time a package author presents a well-written and fairly complete package for inclusion into ELPA, it is too late to make the argument that they should have instead contributed that functionality to a built-in package.  If you can convince them earlier in the process, of course, but it certainly adds to the outside impression that ELPA is a gauntlet that must be run, which I think all agree is not desired.
> 
> I’m not sure I follow.  Most of the time package authors don’t ssy anything until they want to publish the package, so how can the maintainers suggest to them to contribute to  an existing package?

That's a different issue than how to receive new packages with advancements that might have, in an alternate Universe, been contributed to core.   But it's a fair point.

I'm not sure I have a solution to the chicken and egg problem.  Advertising "low-hanging fruit" capabilities that core packages need, and providing starter packs for aspiring package developers?   Perhaps with the explicit offer of the occasional core developer's ear for questions?  I mean the quality of answers here is usually off-scale good.

> An alternative would be for potential package authors to post to emacs-devel, stating that they would like to see feature foo in package bar.  If it turns out that it is not feasible to implement the feature, then sure, a new package can be created.

I could also imagine a yearly "meet and greet with core developers" type of event, where new ideas get passed around, people talk about the packages they'd love to build next, and others in the know can mention how those may relate to or potentially extend core packages.  An old-fashioned spit-balling session.