Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"): > We should go for "weak code ownership" instead,
I was thinking about what Scott wrote, and also went back and read some of the bug log he is referring to. I wonder if there is an underlying a useful observation about the merits of team maintenance. Most of the really bad cases I have seen have been a single maintainer. In packages with more than one person involved, even if there is someone in the team whose communication skils are not brilliant, it is normally possible to work with the rest of the team. There is of course a possibility that a whole team might get a kind of groupthink. I have indeed seen that in a few situations, but it is obviously very rarely practical to replace a whole team, even if a decision to do so could somehow be made. Can we come up with some way whereby the maintainership authority is always shared, somehow ? Either with a team, or with the whole project (QA-style), or with the first person who comes along and wants to try to help ? Is there a way to do this that would work in practice ? Some ideas: * Document that all packages ought to have several maintainers, if there are people available to do that job. * A new rule that for a package where only one human being is named in Maintainer/Uploaders, any DD who wants to help the package SHOULD add themselves to Uploaders and thereby become a maintainer equal in standing to the existing maintainer. That is, discourage NMUing a sole-maintained package, in favour of joining its as a maintainer - importantly, to encourage joining as a maintainer without asking first. So the process would be: Alice sees that a package is solo-maintaineed, and there is something she wants to fix in it. She uploads to NMU/DELAYED-7 adding herself to Maintainers, and maybe fixing any easy RC bugs. She also simultaneously emails the maintainer to introduce herself, offer her help, and consult on plans for the future of the package. Something like: Hi, Bob. I was looking at gnomovision, and saw that you seem to be dealing with it alone. I would like to help so I have taken the liberty of becoming a maintainer, with my upload which I have just pushed to DELAYED-7. I also fixed #890123 (the RC bug) in what I hope is the right way. Please let me know if I got it wrong. To be honest, I don't have a great deal of time for doing major work on gnomovision but I can help deal with obvious problems and help keep the package in tolerable shape. As you will know, we (Debian) recently decided that it's better for me to formally become a maintainer of a package which would otherwise have only one person looking after it. I hope this all seems good to you and I look forward to working with you. Regards, Alice. * Change the dev ref so that if a package has only one maintainer, any upload should be considered a maintainer upload and the usual NMU rules do not need to be followed ? Probably bad because no-one will want to do such a hostile act. * Explicit authority for the MIA team to declare that someone is no longer a maintainer, to avoid Maintainer fields giving the appearance of multiple maintainers when actually there is only one maintainer right now. * Disputes within maintainership teams might have to end up in front of the TC, more often. But then the question is much more "what is the best way to do X or Y". * Maintainership to be recorded elsewhere so that it is not neccessary to upload to change the maintainer. There could be a web UI in which SSO-logged-in DDs could see a "join team for this package" button which would automatically join the team if there was a sole maintainer, but would turn into an "apply to join the team" button if there were at least three existing maintainers. Or something. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.