Re: Technical committee resolution
Anthony Towns <aj@azure.humbug.org.au> writes:
> On Mon, Mar 10, 2008 at 10:45:25PM -0700, Russ Allbery wrote:
>> I'm not sure that Ian deciding that he doesn't think the tech-ctte is
>> functional or fast enough and hence isn't going to even give it an
>> opportunity to be functional is particularly persuasive.
> If the people on the committee aren't willing to use it, that's an easy
> and objective sign of dysfunctionality one way or another. Ian's also
> been on it for its entire existance, and as the proposer of the
> constitution is pretty much its designer, which is worth some weight
> too.
I don't think it's anywhere near that obvious. Other possible reasons for
Ian not to want to use the tech-ctte that come immediately to mind:
* He's in a hurry to do something right now, and going to any deliberative
body to ask for a decision is going to take some time. That's
unavoidable and not something that could be fixed.
* He thinks the tech-ctte might tell him to work it out or otherwise
decide against him rather than bless what he actually wants to do.
* It's easier to ask forgiveness than permission.
Several of these reasons can easily have a subconscious strengthening
effect on an otherwise conscious belief that the tech-ctte doesn't work
(in other words, I'm not accusing Ian of deliberately making any of the
above choices, but I know if I were him I'd be studying myself closely to
see if any of them may be in play).
This is exactly why people recuse themselves from decisions, and why Ian
recused himself from this one. It's hard to be objective about the
capabilities of a governance mechanism when you have a stake in the
outcome and the governance body may decide against you.
>> Do you believe that this issue wasn't resolved because the tech-ctte
>> members have been serving for too long? And if so, why?
> No, I believe that the technical committee isn't working, and that
> without the accountability that results from other people being involved
> in tech-ctte decisions, and the new ideas and enthusiasm that results
> from new people becoming involved, it won't improve.
> And without both those things, even if it improves now, it will stagnate
> again in future.
I almost mentioned this in my previous message but I didn't want to read
your mind. But since it does seem to be what you're saying....
My impression is that you feel like a shakeup is useful for a body that
you think has stagnated even if that shakeup has no specific effect on the
problems, just on the grounds that a shakeup will get things moving again.
I disagree strongly with this position; I think this sort of approach to
governance bodies is highly counter-productive and ends up just wasting a
bunch of time and energy that's already scarce.
I don't see any problem with the tech-ctte that can be traced to a lack of
accountability, as opposed to a variety of far more mundane problems such
as lack of time and lack of sufficient energy, none of which are likely,
IMO, to be fixed by forcibly cycling members. I think you need a much
more compelling argument for the specific change that you want to make.
> Sven's conflict with Frans, the d-i team and others is probably the most
> extreme example of a problem we've had to resolve. It was escalated to
> the DPL, to the tech-ctte, to DAM, to ftpmaster and others. Of all
> those, the tech-ctte was the least able to execute on its mandate, even
> in so far as simply saying "We're sorry, we're not going to resolve this
> for either of you" in a timely manner.
I'm not going to discuss this any further other than to reiterate that I
strongly disagree with using Sven Luther's case as a basis for any changes
to Debian governance structures. It is in my opinion a prime example of
"hard cases make bad law."
> There's two reasons. One is for the health of the committee itself: if
> you don't get practice resolving technical issues when there isn't a
> conflict, you're going to have a hard job doing so when there is. The
> other is simply that it's one of the committee's constitutional jobs:
> "decide on any matter of technical policy". Since the committee hasn't
> ever done that, it's been picked up by the policy team, release managers
> and others, with a fair amount of success (otherwise Debian would've
> been screwed long ago), but it's the constitutionally appointed body
> that should have those teams' back on policy issues.
This, however, I find a really interesting argument. I'm not sure it
would actually work, but using the tech-ctte as a final arbitrator of
Policy decisions and actually using that appeal on a regular basis is
something that Manoj and I have both talked about, something that has
constitutional support, and something that may very well work.
This is something that we could try now without making any changes to the
tech-ctte, if the tech-ctte is interested. If we tried it for a while,
we'd have more data to use to determine whether rotating the membership of
the tech-ctte would be useful.
Have you raised this idea with the tech-ctte? What do the other members
think of having review of Policy change proposals be part of the tech-ctte
job? How would the mechanics of this work? (Manoj's Policy change
proposal has the tech-ctte as an automatic appeal for any rejected Policy
change, but this sounds more active than that to me.)
>>> Or you could look at the value of past decisions made by the ctte, via
>>> the ctte web page www.debian.org/devel/tech-ctte.
>> What that page says to me is that people aren't using the tech-ctte.
> No, that's not true; that page doesn't include times when people have
> tried to pass decisions to the technical committee, and the committee
> hasn't managed to come up with an answer at all. That page is the
> committee's successes such as they are; it ignores its failures.
Okay. Well, the tech-ctte bug page also says the same thing to me, so I
think the conclusion is still valid, unless those appeals aren't on the
bug page either.
>> We resolve most of our problems through significantly less
>> confrontational methods than a tech-ctte vote.
> Like a package hijack? Or a BTS war or entry in $gFuckheads? Or an RM
> edict? Or an ftpmaster tweak to dak? Or calling people idiots on mailing
> lists? Or a listban? Or a general resolution? Or forking? Or just
> letting the maintainer do whatever they want?
Usually we don't use those methods either, but point. :)
>> However, to the degree that the paucity of decisions is due to a lack
>> of confidence in the tech-ctte, I agree that's a problem that would be
>> nice to fix.
>
> You say that like the lack of confidence isn't justified.
I personally don't think that it is, and you haven't as yet convinced me
otherwise. *shrug*. Looking at the membership of the tech-ctte, I have a
great deal of confidence in decisions made by that set of people, and as
yet I've not seen anything in the evidence you've cited that changes that.
> There are definitely people outside the committee who are in general
> equally capable as those currently on it, and who are more capable in
> specific areas. I don't have anyone in particular in mind, but I would
> be more comfortable making suggestions if I thought that it'd be for a
> limited period (just in case they turn out crazy), or that other
> positions would open up predictably (so that it wasn't just a one off
> "let's add some people" without being a part of ongoing revitalisation.
Ah, okay, this is another interesting point, and I can see where you're
going with this. I agree, this is a place where having some sort of limit
or provisional membership might be useful, in that it reduces the severity
of bad decisiosn. On the other hand, I don't think that the most likely
failure mode is to put someone on the tech-ctte who makes bad decisions;
the most likely failure mode is to put someone on the tech-ctte who
doesn't have time, and that is easier to deal with.
> Replacing the longest serving member with someone else makes it easy to
> get new ideas and knowledge into the committee, and avoid having an
> aristocracy/priesthood/whatever of developers who think they're above
> the rules everyone else abides by, without having to criticise the
> existing members, either directly if you need a vote for their removal,
> or by implication if you just have to pick whoever you're replacing.
I don't believe that any of those things are being created by the current
tech-ctte structure. In fact, were I a tech-ctte member, I would find
some of the descriptive terms you use in this paragraph to be rather
offensive.
>> Here, the tech-ctte specifically voted that precise bug severities were
>> not a technical issue and they weren't interested in taking this on.
>> I'm pretty sympathetic, as that whole thing looked like a tempest in a
>> teapot to me.
>
> So in that case, there was a dispute over whether 97671 was an RC bug or
> not,
That's not what the bug log says; the bug log says that the bug was being
treated as <suite>-ignore, essentially, and hence not RC. If I'm not
mistaken, this whole discussion predated the use of the <suite>-ignore
tag, which would be the obvious solution to this problem should it recur.
At the time, it was a request for the tech-ctte to set a binding precedent
on who controls bug severity for a bug that isn't RC: objective standards
or the maintainer. In my opinion, the correct thing to do at the time and
with that situation is to decline to set any binding precendent since both
possible binding precedents would have been bad ideas.
Hence, I think the tech-ctte did exactly the right thing with that bug.
Now that we have <suite>-ignore, if the same problem were raised again,
I'd say that the bug should stay serious and be tagged lenny-ignore.
> Would we be better off if we had a body other than
> ftpmaster/debbugs/RM/DSA/etc could (and would) resolve disputes?
Yes. I do agree with this.
> I think we would. Most of those groups would prefer to be focussed on
> their technical issues, rather than having to also decide when a
> maintainer or developer is being a jerk and needs to be overruled, at
> least in my experience. And it's good if there's someone around who can
> overrule those groups themselves. Having the technical committee
> undertake that role effectively and competently would make life a bunch
> easier on those teams, IMO.
I think I agree with this too. I'm just skeptical that this is the right
way to get there.
>> (2) here is again a question of follow-through, and I don't see how
>> your proposal addresses that. The problem again is that someone has to
>> do work, and you can't, in general, find people to do work by doing
>> governance shuffling.
> Eh? You can _only_ find people to do work if you can transfer the
> ability to do work from people who aren't doing it, to someone else.
Uh, you don't need term limits to appoint new people to the tech-ctte.
As near as I can tell, the basis of your proposal is to replace the
existing members, who you don't feel are energetic enough, with new
members, who you hope will be more energetic simply by fact of being new.
My guess is that you'll find a substantial percentage of new appointees
will just disappear and end up doing even less than the current members.
I think you're using a hammer to turn a screw. If there are people out
there with energy to tackle tech-ctte problems, you can add them right
now, without needing governance changes. You only need governance changes
if the tech-ctte refuses to appoint new people with more time, and I don't
see the evidence that this has been tried. Clearly you think the
tech-ctte needs more energy and help -- why not open a call for volunteers
and move forward that way? Or pick a few people who you think would be
good, get some consensus in the tech-ctte, and try to draft them?
> That there is no mechanism for people outside the committee to hold it
> accountable is a problem even if the committee were currently working
> perfectly.
I've seen no sign of problems caused by accountability so far in this
thread.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: