Here are my 2 cents of the topic in general - unmaintained packages are not an Emacs-specific issue and they exist in every programming community. I don't really think we need some special policy on handling them, as:

- if a package is really valuable new maintainers will always be found
- if something is in a really bad state people will just stop using it

Spending our limited efforts on policing the ELPA packages and trying to decide if something is "properly maintained" is not going to amount to much IMO. If someone uses a package and thinks it's valuable then it probably is. A package doesn't need to be perfect to be useful.

It feels to me there's no real problem to be solved here. If we want to discuss what to do about specific packages (e.g. yasnippet) to improve their state - that's a completely different topic. 

On Wed, Jun 1, 2022, at 1:08 AM, João Távora wrote:
> On Tue, May 31, 2022, 17:42 Philip Kaludercic <philipk@posteo.net> wrote:
> 
>> To be specific, my issue was mentioned here:
>> https://github.com/joaotavora/yasnippet/issues/1121 ("Avoid
>> false-positives when expanding snippets").  In my case, I have managed
>> to circumvent the issue by unbinding the tab key and relying in
>> hippie-expand, but the solution is not elegant and I would have
>> appreciated a discussion on the issue tracker.
> 
> Does it really matter where the discussion happens? The problem 
> here is not the place, it's the unavailability of brain-hours to dedicate 
> to your request.
> 
>> The point was not to say that yasnippet has been abandoned, just to give
>> an example where the liveliness of development could be questioned.
> 
> You don't have to sugar-coat it. Yasnippet's bug reports have gone unanswered 
> at least for a year. They don't make it into my inbox, I'm not the maintainer
> anymore. Noam did a thorough and excellent job while he was maintaining it, 
> he's not available anymore. It's de facto unmaintained, though rather stable 
> in its intended use case.  Of course Emacs is gigantic and everyone wants 
> everything, and so it might not be doing what you want.  I understand that.
> 
> 
> In that sense, it'd be nice if yasnippet wasn't' the monolithic package it is, 
> and 'snippet.el' is a step in that direction.  Then you could perhaps opt out 
> (or in) to the multi-file, keybinding, abbrev-like functionality of yasnippet.el.  
> Or simply compose 'snippet.el' bare-bones expansion/navigation with 
> whatever other productivity tool where you think  snippets make sense. 
> Eglot is one of those tools and it works well with yasnippet today.  I'd love to
> make it depend on simply 'snippet.el'.
> 
>> > Is it just the general idea of abandonment of the fact that people's
>> > issue reports go unanswered?  If the latter, then I think archiving to
>> > the repo would make sense.  No more issue reports would come in and
>> > one could advertise the Emacs bug tracker.  Would that improve things?
>> 
>> I guess, but I think it would be preferable to call for someone to fork
>> the package instead of shifting the burden of maintenance onto the emacs
>> bug tracker.
> 
> Again, i don't quite understand how that magically solves the root problem
> You're free to fork when you want, of course, but that normally happens 
> when you want to take the software in a new irreconcilable new direction.
> 
> Currently, yasnippet just needs (1) a maintainer that understands the 
> current functionality and "protects" it, fixing bugs, not introducing new ones.
> New features are probably not a great idea. (2) someone to develop 'snippet.el' 
> into production-ready state and make 'yasnippet.el' depend on it, then may 
> integrate make 'snippet.el' into a new package. The person of (1) and (2) can 
> be the same.
> 
>> > it motivates someone to pick up the maintenance of the existing
>> > Yasnippet.
>> 
>> Due to a sudden increase in free time available to me, I might consider
>> this.
> 
> Great, if you're serious about it drop me a line stating more or less what
> your plan is. I don't know if you've read the code: it's not exactly a work 
> of art (at least my parts aren't) :-) If you'd prefer a more palatable challenge, 
> you could opt to simply develop the somewhat nicer 'snippet.el'.  It'd be fine 
> to create your own repo to host and develop it (say in that shiny SourceHut
> account where we discussed a bug the other day). 
> 
> João
> 
> PS: in the meantime, it seems that Dmitry suggested what seems like a 
> reasonable way to address your request.
> 
>