In our current arrangements, the TC is the only body who can rescue a package from a maintainer who is determined to sit on it.[1]
The TC have never exercised this power, when a maintainer has insisted that they want to keep maintaining the package. It is surely obvious that there must have been several occasions in the history of the project, where someone has been such a poor maintainer that they ought to have been deposed, with someone ready to take up the role. The only possible conclusion is that our process for dealing with bad leadership on the part of maintainers is totally broken. There is a recent case where: * The maintainer has done nothing to the package for many years, other than infrequent (and usually short) emails to NAK contributions from others; * The package is years out of date compared to upstream, afflicted by bitrot, and many users are asking for the new version; * Several times, proposed updates have been prepared by contributors but blocked by the maintainer; * There are new maintainers ready and waiting, with a new package ready for upload to sid for stretch; * Now that the TC is involved the maintainer has written many emails explaining their decisions to NAK uploads, but TC members are clearly unconvinced on a technical level that those decisions were right. Even in this extreme situation the TC has not seen fit to wrest the package away from the mainainer's deathgrip. I don't know exactly why the TC is so useless at challenging poor maintainership. I think part of it is that our TC is supposedly focused on technical issues. The TC likes to try to solve a technical problem while "keeping everyone happy". This is of no help if real underlying cause of the technical problems is not a technical disagreement, but rather poor management by the maintainer. In that case "keeping everyone happy" means keeping the most stubborn people happy. It means keeping the bad manager in charge, while those who don't want to fight simply go away, discouraged. TC members tend to reframe efforts to solve the leadership problem, as personal attacks. And of course, that is a real difficulty: since maintainership is a personal authority, it is hard to suggest that someone's authority should be weakened without criticising how it has been wielded, and implicitly criticising that person. I also think that TC members are probably biased, by selection. All TC members have extensive experience of maintainership (either within or outside Debian), and/or of core team membership. They have long experience of wielding authority, and of negotiating from a position of authority with peers. They will probably have had recent (and to them salient) experience of being challenged by useless supplicants; whereas their experiences of being blocked or rebuffed by useless maintainers will have been less common, and have less of an overall impact on their participation in Debian. This will tend to make TC members more comfortable with the existing massive power imbalance between maintainers on one hand, and other contributors on the other. And of course for very good reassons, many of the kind of people we put on the TC are very conservative: they tend not to like change, particularly change to social structures. Other difficulties include the requirement for transparency in TC deliberations; and the difficulty of dealing simultaneously with social and technical problems (and the consequent temptation of technically focused people to just fix the software, where answers are clearer, and think or hope that that is enough). Regardless of the reasons, this is not good enough. Maintainership is a leadership position, with serious governance authority. Leaders must be accountable. Bad leaders must be replaced. It is clear to me that the TC (the structure I set up for this purpose when I wrote the constitution) is not delivering and probably never will. There are three obvious options: 1. Recognise that Debian will never depose a maintainer, no matter what. Maintainers are, within their packages, dictators (subject only to the possibility of TC overrule on individual issues, which is itself very very rare). The only way to get rid of a bad maintainer is to wear them down unti they eventually go away. 2. Provide a new process for deposing a maintainer, or appointing co-maintainers. 3. Abolish maintainership entirely. Of these 1 is what we have now. I think it is entirely unacceptable. I don't think the project is politically ready for 3. Also, it would be awkward to see how 3 would work in practice: are competing contributors expected to play core wars in the archive until the TC makes a decision in each case ? What a nightmare. That leaves 2. The key question for such a new process is: who will decide ? It is very tempting to model such a thing on our existing constitutional structures. For example, we could create a team like DAM, whose job was to take (private) requests for mediation/intervention, and who would eventually make some kind of decision. But I would like to make a more radical suggestion. We should make these decision by juries, rather than committee. For each such dispute, we should pick a panel of randomly chosen DDs, and have them decide (with a time limit). In more detail: An aggrieved contributor, the complainant, would first contact a mediation team, privately. There would be some overlap with MIA, I guess. Hopefully things can be resolved through mediation. If the mediation does not result in satisfaction, a DD complainant would send an email to a robot, giving the names and addresses of co-complainants. The robot would select a random panel of (say) 10 DD. (There would probably have to be a ping back phase to make sure the chosen weren't MIA.) There robot would set up two mailing lists: the panel; and the complaints and existing maintainers together (for the maintainers, personal addresses, from, Uploaders, for a "team" maintained package). The complainants would send an initial summary to both lists; the maintainers would prepare an initial reply, to both lists. Messages to the panel list but not the two-sides list, other than from panel members, would be rejected. If a panel member feels that private input is required from one side, they can ask for it and forward it themselves. The panel would discuss matters for a period of two weeks. The complainants and maintainers would be CC'd on the initial mails. At the end of two weeks they would vote. By a simple majority, the panel either reaffirms the maintainership of the existing maintainers/uploaders, or transfers formal maintainership to people nominated[2] by the complainants. We would implement this constitutionally by giving the DPL the power to define a process by which maintainers may be replaced. Probably the GR would come with an initial cut of that process. Ian. [1] In theory deposing a maintainer could be done by a GR but that would be a nightmare. [2] Nomination of the new maintainers should be done at this stage. Thus a a frustrated contributor who, if the petition fails, needs goodwill of the curent maintainer, can ask others to front the complaint and argue the case. This helps minimise the justified fear of retaliation. -- 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.