I think this proposal is a little bit too complicated and not straightforward
enough.
Clearly we have two different situations:
* Maintainer is not active and we want to orphan a particular package.
(just to orphan without adoption)
For this case filing a bug "please orphan this package" with CC to QA team
seems reasonable mostly because MIA may be an overkill (what if maintainer
just don't have enough time with the absence of co-maintainers? Also consider
the case of prioritising when active maintainer may be working hard on more
important issues).
Also MIA procedure (if applicable) may take too long -- it is not unusual when
it takes 6 months or more to complete MIA checks and orphan all packages.
If "please orphan this package" bug is answered (or closed) by maintainer it
clarifies the situation immediately.
Obviously anyone can update the bug with objections in which case we need some
form of consensus to proceed. I would leave the decision to QA team as they
are handling orphaning anyway.
If bug was unanswered for let's say two months the package is free to orphan
by QA team. I believe one month won't be enough: maintainer might be without
connectivity while changing internet providers, attending funeral overseas,
being on long vacation, on maternity leave, relocating, changing jobs etc.
Such reasons can easily keep maintainer offline for a month.
This will work if QA team won't hesitate to orphan in obvious cases.
----
Another (second) situation:
* Maintainer is not active and somebody intended to take over the package.
I think proposal is addressing this case in order to protect package
ownership. I believe generally we should trust developers (DDs) and avoid
unnecessary bureaucracy. If DD is going to snatch the package without waiting,
asking or following the procedure it would be a case for technical committee
to investigate.
Practically speaking taking over the package often bypasses orphaning.
Either developers decide between themselves or new maintainer declares (her|
him)self as such.
The question is whenever we want package to be orphaned first, which I believe
is unnecessary as long as new maintainer publicly announce ITA.
Also I think we should trust DDs to decide how long to wait for maintainer to
reply. One month seems reasonable but it depends: timing may be important
before freeze or if package is blocking other packages. Proposal can recommend
to wait one month, ideally two.
As for DMs or non-members they would have to find sponsor to review their work
anyway so we don't need a procedure to protect package ownership from
hijacking by non-DDs.
I like the idea of filing ITA against the package in question. It clearly mark
the intention to work on the package and notifies the maintainer
automatically. It doesn't have to be called "ITA" -- we can call it "co-
maintainership intent" or whatever.
Consensus 3 to 1 will be only needed if there are any objections but that's
common sense. In obvious cases a single developer's decision should be just
enough for adoption.
I believe we're all respect each others work and our intentions are good so we
need only little clarification how to adopt a package respectfully.
For example I would mention to keep old maintainer in Uploaders unless
(she/he) agreed to retire from maintenance.
All the best,
Dmitry.
Attachment:
signature.asc
Description: This is a digitally signed message part.