I think the summary of problems facing the TC is really good and a great starting point for discussion. In another message I proposed one additional problem, but regardless of whether the TC agrees with that, you've given a good starting point. My biggest take away from the set of problems and the set of proposals is that we don't know what the right answer is. To that end, I'd like to make a meta proposal: make it easy for us to try new things until we find something that works. The current constitution makes that hard: 1) Changing things like the balance between design and body of last resort require a constitutional amendment. 2) Making decisions by vote is hard-coded. Other bodies like the ftp team and release team that regularly deal with technical issues have much more flexibility in their decision process. I suspect that these limitations were intentional in the original constitution. We wanted to protect individual maintainers. Particularly given the climate in which the constitution was drafted, having individuals (such as the DPL) or bodies with too much power was undesirable. And of of course it still is. And yet, we've struck a balance with delegates that seems to work at least better than the TC even for some very core processes. Yeah, there are frustrations when teams get slow to respond and there are things to iron out. But the basic idea of deciding as a community the broad aspects of responsibility (and the few limits we need to feel comfortable), delegating to individuals, and letting those individuals establish things within the constraints of their delegation has worked fairly well. Sometimes we specify more in the delegation when the community feels it needs that. Sometimes we specify less. So, I'd like to see us get rid of the constitutional special case for the TC and instead, allow these powers to be delegated. My intent is not to get rid of the TC, only to allow us to refine it much more rapidly. In particular I propose: 1) Constitution 8.1(2) lists powers that delegates may have but the DPL clearly does not have themselves. I propose to add most TC powers to that list: * Set technical policy * Make decisions where there is overlapping responsibility [1] * Override a maintainer's decision * Choose who maintains a package [1] Some care would be needed not to take away power from the DPL; there are cases where the DPL acts when there are overlapping interests today. 2) Remove most of section 6. This leaves a dangling question of the role of the TC chair in acting with the secretary when the DPL is not available. I can think of solutions to that, but in the interest of focusing on the TC aspects of that, I'll defer that for now. 3) Explicitly look through section 6.1 and make sure that all the powers there are accounted somehow. If we get to a place where it would be helpful I'm happy to draft specific constitutional text. I don't think we are at that stage now. I think that giving us flexibility is the biggest thing to do here. But let's take a look at a specific way that these powers could be used to implement something along the lines of some of the proposals considered. Delegate the TC. Encourage involvement at two stages: 1) Come to the TC early if you have a change that is likely to impact significantly more than your own package. The TC can give advice on whether you've reached out to the right stakeholders and help make sure you've gotten the (technical and other) input you need. 2) Come to the TC later if there are conflicts that affects packages and the like. I kind of imagine that for each release there would be a change proposal deadline. If you submitted your cross-concern proposal before this deadline and collected input from the suggested stakeholders then there would be a strong presumption your proposal got to go forward. If in contrast you didn't seek input early, and people ran into conflicts with your proposal, the TC might be a lot more likely to suggest (or insist) that things hold off for a release. I think something like that to get the TC involved earlier and in a constructive helping-out role rather than a saying-no role might really help. I'm sure any such proposal would need refinement. I hope we choose to give ourselves the tools to facilitate that refinement without a series of GRs.
Attachment:
signature.asc
Description: PGP signature