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.