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.
signature.asc
Description: PGP signature
