Ian Jackson <ijackson@chiark.greenend.org.uk> writes: Ian, my apologies for the delay. I promised you after our dinner conversation at Debconf that I would try to articulate my concerns with this GR proposal. Here's my best stab at it as of today... > In the past the Technical Committee have been reluctant to overrule > a maintainer unless all the members are absolutely convinced that > the maintainer's decision was wrong. I disagree with this assertion. I'd be happier if the text focused on the effect rather than the possible motivation. That effect might be that the TC has appeared to be slow to bring such motions to a vote? If so, saying that without trying to guess at committee member motivations would make me happier about this paragraph of preamble. > The TC has sought the views of the Developers. Accordingly, the > Developers advise, in their (non-binding) opinion, that: > > ----- GENERAL RESOLUTION OPTION A ----- > > The Technical Committee's approach so far has been correct. > > ----- GENERAL RESOLUTION OPTION B ----- > > Technical Committee members should be willing to vote to overrule if > they feel that the maintainer's decision was wrong; the > supermajority requirement is sufficient to guard against overruling > in questionable cases. So, continuing my thought above, the problem with this proposed GR in my mind is that I already feel willing to vote to overrule if I feel the maintainer's decision was wrong. So it's not clear to me that this GR as worded would "give me any new information" from the Developers. One reason I can think of that *I* think has caused some such motions to not be acted on very promptly in the past are honest differences of opinion about what is right and wrong, that led to a perceived lack of consensus. In those cases, maybe just voting on it and gaining a concrete sense of the position of the TC might have been more effective in some cases than waiting to try and build a stronger consensus? The other reason I can think of that some such motions don't get taken to a vote quickly is when a specific local decision might seem wrong, but choosing to vote to overrule the maintainer feels like it might do more harm to the overall project than allowing the maintainer's apparently bad "local" decision to stand. I'm having a hard time articulating a specific example of this, but I have the sense that this may be one root cause of delay in some of the "who should be the maintainer of this thing" questions we've faced in the past. Where this leaves me is that while I do not object at all to the idea of using a GR to discover the consensus of Developer opinion on when to overrule a maintainer, I'm not happy about the assertion of motives in the preamble, and remain unconvinced that the alternatives as written would actually lead *me* to an actionable change in personal behavior regarding voting on TC motions. That causes me to question the utility of this proposed GR. Bdale
Attachment:
pgpkNjlWuMRGg.pgp
Description: PGP signature