Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
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.
Reply to: