Third-party removal policy: unmaintained projects

[srittau]

Cf. #12848 and #12847. I suggest to amend our removal policy to say:

Third-party stubs are generally removed from typeshed when one of the
following criteria is met:

• The upstream package ships a py.typed file for at least six months,
  and the upstream type annotations are of a comparable standard to those in
  typeshed,
• the package does not support any of the Python versions supported by
  typeshed, or
• the package is no longer maintained.

With the third criterion being new. The wording ("generally") leaves us some wiggle room in case we want to continue supporting stubs for an unmaintained package.

[AlexWaygood]

This makes sense to me, and we've already been following this for some stubs packages. But we'll inevitably have conversations about what it means for a project to be "unmaintained" if we leave it undefined. How about we define this as "the package is either archived, publicly declared as unmaintained/abandoned/deprecated, or has had no commits to the default branch for 2 years or more"?

[srittau]

Personally, I would prefer not to define this - at least for now. I'd expect this to mainly be a fallback clause when something starts to break (like now with boto and playsound), and to be applied fairly infrequently. This gives us more flexibility, and I don't expect these to be overly contentious.

If it turns out we are invoking that clause frequently - or it causes contention - we could always narrow it down later on with the experience gathered.

[AlexWaygood]

Maybe we could explicitly acknowledge that it's a subjective call, in that case? "The package appears, according to the best judgement of the typeshed maintainers, to be unmaintained"?

[srittau]

That sounds fine to me.

[JelleZijlstra]

If we anticipate doing this mostly when the package causes maintenance problems (e.g., it doesn't import on new Python versions), then we should probably make that explicit. Some unmaintained projects may still be in use and work fine, and keeping them in typeshed gives users the opportunity to improve the stubs.

[AlexWaygood]

Synthesis: we should try to use a wording that retains flexibility for us but is also explicit about specific situations where we know we might often use this new criterion

[Avasam]

I think it's worth spelling out the case where a package's status is "unmaintained" simply because the next version has changed name (a few historical examples, not necessarily related to typeshed: boto -> boto3, PySide --> PySide2 -> Pyside6, winrt --> winsdk -> PyWinRT, BeautifulSoup -> beautifulsoup4, PIL --> Pillow, sk* -> scikit-*)

I don't feel that differently about this case as I do dropping NumPy v1 support for NumPy v2.

(I know this doesn't answer the general case of an unmaintained package causing us maintenance issues, but I think its one of the good justifications we can use)