Dear Technical Committee: I'd like to ask you to consider an additional problem with the current TC structure that I don't think was called out clearly enough in your mail to debian-devel-announce. Currently, the TC is the only body that can change who is the maintainer of a package. Unfortunately, for almost all of the situations where this would be desirable, the TC process is a remarkably bad fit. Most of the reasons are things that you explicitly called out in your mail, but given how bad this situation is, I'd like to call it out explicitly and ask us to evaluate whether solutions make this better as part of considering proposals for change. The TC process is bad for disputes involving who should be a maintainer of a package for reasons including: * These disputes by their nature are generally not of a technical nature, and I suspect have never been entirely technical. * Holding such discussions in public makes them much more confrontational than they would otherwise be. * Because of its decision making process, it's somewhat challenging for the TC to work with other bodies involved in dispute resolution like the DPL, the community team, etc. * Those other bodies are generally delegates (or the DPL) and there are aspects of that difference that can potentially get in the way. For example it might be really valuable to handle an issue jointly with the CT and TC. ---------------------------------------- I'm not the first person who has raised concerns about how challenging it is to consider the question of changing maintainership of a package. I agree with many of the issues brought up in previous rounds of this discussion although not so much with the tone in which they were presented. I do think this is a serious problem based on my term as project leader. All too often you would run into situations where someone would get blocked by a maintainer and there was just nothing that could happen. And I'm not talking about anything to do with init systems at all here. But for example when maintainers ignored the release team, or wouldn't respond when people tried to engage with them, it ended up being very demotivating. I do not pretend to know what the right answer is for a threshold for when that should become a problem where the project considers making a change. I do claim that we don't have the tools to consider that today. --Sam
Attachment:
signature.asc
Description: PGP signature