This is a bit of a dead issue now, but I wanted to come back to it: Steve Langasek writes ("Bug#682010: [mumble] Communication failures due to CELT codec library removal"): > On Fri, Jul 20, 2012 at 02:48:07PM -0700, Don Armstrong wrote: > > The objection is that the issue has been raised before the CTTE, so it > > needs to be resolved first before action is taken. > > If the original petitioner is satisfied with the solution and no longer > feels the need to involve the TC, I don't see any reason for the TC to > remain involved. Certainly historically, we have considered our job done > once there's no longer a dispute that someone wants escalated to the > committee. It's not at all our charter to fix all the bad bugs, only to > adjudicate when consensus can't be reached on its own. If Chris and Ron > *are* working together now towards an agreed solution, I'd much prefer that > we let them get on with it.
I think this is the right approach when it seems that all the important aspects of the problem have been considered by everyone. I don't think, though, that we should have a hard and fast rule that we should drop a case immediately as soon as the referrer (the person who brought the matter to the TC) says once that they are satisfied. In particular if it appears that the referrer may be acting in haste or out of only a partial understanding, it is part of our job to ask questions and double check. It seemed to me at the time that Chris's understanding might not have been complete. Ron was very keen to get his particular understanding implemented ASAP, but I thought a more reflective approach was warranted. And indeed after Chris had a bit more time to think about it and do some more checks it turned out that things were more complicated than they seemed. > It may be that it's Ian's intention to take up this issue in Chris's stead > because he himself thinks there's a problem that he wants to put before the > TC. That's fine too, but I think in that case, Ian, you should state this > explicitly I didn't intend to take this up in Chris's stead. And indeed if the parties come up with a solution which Chris and other parties are happy with after appropriate reflection and consideration, and which meets our goals in this context for wheezy, then it seems unlikely to me that the TC would need to do anything. However having said that as a matter of procedure I think that once a dispute has been brought to the TC, the TC is /entitled/ to make a decision even if the original referrer has changed their mind. Usually it wouldn't be appropriate or necessary for us to do so, but I think the power is there. As an example of a hypothetical situation in which we would exercise this power: suppose the maintainer whose decision is being referred abuses social pressure of some kind to persuade the referrer to withdraw the referral (perhaps just by being rude or by threatening some kind of retaliation). Just to be clear, I'm not accusing anyone in this dispute of having done any such thing to Chris. If such a situation arose I'm sure the TC should make a ruling regardless; and if the TC has the power to rule in such an unpleasant hypothetical situation, it seems to me it also has the power to (for example) delay disposing of a work item while the TC's members make sure the referrer and others have properly considered all of the implications. > (and, logically, recuse yourself from voting on it under 6.1.2, > 6.1.3, or 6.1.4 since you're then a party to the disagreement). Of course there is no requirement for TC members to recuse themselves from voting on issues for which they are one of the referrers. The only exception is clearly stated in 6.3(2) and applies when the TC is voting whether to overrule one of its own members. This seems to me to be related to the issue of whether TC members should recuse themselves from voting on matters where they've already previously expressed an opinion. We have consistently rejected such a rule. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20493.20833.120226.584...@chiark.greenend.org.uk