Re: Technical committee workflow
Andreas Barth writes ("Re: Technical committee workflow"):
> Ian Jackson (ian@davenant.greenend.org.uk) [081231 18:20]:
> > * The Rapporteur discusses the issue - off the main TC list - with
> > the various parties. debian-devel might be a good place, with
> > an initial CC to other lists and the bug of course. Other TC
> > members could participate there if they had time available.
> > Other Developers could show their usefulness as future TC
> > candidates by their contributions to these discussions.
>
> I'd like to see the discussion either on list or in the relevant bug
> report(s) so that other people can follow the discussion if needed. (Or
> re-read it, or whatever.)
I think it would be sufficient to have a note in the bug giving the
discussion title in debian-devel, and to have the debian-devel thread
have the bug number. We can use the debian-devel archives to review
if necessary.
The advantages of using debian-devel are:
* This is where disputed or difficult matters are discussed already
so it is where de facto disputes currently get resolved (since the
TC is rarely invoked and even more rarely acts)
* It has a wide range of participants who in technical threads often
bring useful information to bear. Issues discussed on debian-devel
have much wider exposure than those on the TC list.
* It provides a much lower barrier to entry for people who want to
contribute - the TC list is a separate list and of course there are
the perennial arguments about subscriber-only posting.
* The primary discussion does not need to be copied to every TC
member. This keeps the TC list low traffic and preserves TC
members' focus on issues that haven't been resolved by the
Rapporteur process.
* Separating the full TC from the discussion means that the TC
works effectively as a review body for the Rapporteur rather than a
primary decision body.
> I'd also like a provision that allows the tech ctte to reassign the issue
> to another member if wanted (not that I expect that to happen, but
> anyways).
Oh, absolutely.
> > * If the parties are not satisfied with the Rapporteur's opinion,
> > the Rapporteur would come back to the whole committee and present
> > their report. Obviously this involves discussing the matter again
> > but now we will have one person whose clear role it is to drive the
> > process.
>
> I'd like us to have something like "at least one TC member needs to agree
> within <timeframe> that we need further discussion, or the tech ctte voted
> as the Rapporteurs report is".
Yes, that's along the lines of my idea. The idea of setting a
deadline for objections is very good.
> With the current constitution rules, I fear we cannot set that as a formal
> policy, but we can agree within us that in case none of the members
> considers it necessary to discuss, we'll just vote about the
> recommendations and follow them, and be done with it.
Yes, absolutely.
I would suggest that the way to implement my proposal would be to
write it up in slightly (but not much) more detail, and pass it as a
TC resolution. "The Technical Committee expresses its intent to do
XYZ but reserves the right to use its discretion in a specific case
and/or change its mind".
It occurs to me that one other thing we should do is this:
If the TC votes Further Discussion (effectively rejecting the
Rapporteur's report) it should appoint a new Rapporteur. At this
point the new Rapporteur should be elected from amongst those who
voted ranking FD above the Rapporteur's report.
The Rapporteur's final responsibility would be to propose the
relevant set of resolutions, call for a vote on it, and vote - they
can do this as soon as they see their own report rejected.
Steve Langasek writes ("Re: Technical committee workflow"):
> > * When an issue comes in, the first TC member to get to it and claim
> > it becomes primarily responsible for it. We'll call them the
> > Rapporteur.
>
> Having designated committee members be responsible for shepherding
> individual issues is a good idea. I believe we were at least nominally
> trying this at one point; I'm not sure if any of the issues assigned this
> way were followed through to completion, but none of the bugs currently on
> http://bugs.debian.org/tech-ctte appear to have bug owners, which ought to
> be part of the procedure if it isn't already.
Yes, absolutely, that's very much necessary.
But what we tried before was not the same as what I'm proposing in
three important respects:
* There was no expectation that the responsible TC member would do
more than chase. In particular, they were not expected to be
the primary decisionmaker. In my proposal the Rapporteur will be
expected to personally come to a conclusion and write it up in a
report.
* There was no explicit timeframe set within which the responsible TC
member should come to a conclusion.
* There was no expectation that the TC would usually uphold the
Rapporteur's decision.
> I also think this discussion should take place in the bug report, which is
> subsequently proxied to the TC list. The full rationale should be readily
> available for inspection, whether or not other members of the TC have time
> to participate in the discussion.
I agree that the full rationale and discussion should be public and
available. I'm suggesting that the public and available place should
be one that TC members can choose to give lower priority than other TC
business.
As I say, the advantages of using -devel are compelling. I think we
can make the cross-referencing work so that interested committee
members can find the discussion easily.
> > * The Rapporteur would issue a report which explains
> > - relevant facts
> > - the arguments made by all sides, including those
> > arguments the Rapporteur rejects
> > - the Rapporteur's conclusions
> > - a decision about what should happen and a timeframe
> > and if they don't do this within 14 days then they can be
> > relieved by any other TC member.
>
> I don't know that a 14-day time limit is all that much of a stick. Why is
> this better than letting members pass on bugs in an ad-hoc manner when they
> need to?
I think this, and your other response, mean that you haven't quite
understood my proposal.
My idea is that the Rapporteur would be given real power. Well, very
real influence at least. They are expected to lead the discussion;
the other TC members are not necessarily expected to participate
heavily (although they may). The Rapporteur's report will normally be
accepted by the committee.
So any Rapporteur will not want to be relieved because having taken
ownership of the issue they'll want to retain it. That means that if
we set a deadline at which the Rapporteur is automatically relieved,
we set an expectation amongst all the participants giving input to the
Rapporteur that the discussion should be conducted expeditiously - in
particular, that if they want to say something they'd best say it
soon.
This works as a direct encouragement to the Rapporteur, to keep
focussed on the discussion during a limited period of time. And of
course it limits the time commitment of the Rapporteur, who when
claiming an issue need not fear it dragging on for months. The
imposition of workload on the Rapporteur has a finite duration.
> > We'd have to have some rule to avoid a fast-replying TC member from
> > getting all of the business: perhaps, if you're the person who took
> > the last issue, you must wait 72 hours before claiming a new one; if
> > you're the person who took the second-last one, you must wait 48
> > hours.
>
> Why? Surely if a member of the committee is able to resolve these issues to
> everyone's satisfaction, there's no need to rate limit?
As I say, the plan is the give the Rapporteur real power. We need to
keep it fair.
> For the most part I think the workflow described is reasonable, but no
> amount of good process will make up for TC members simply not spending time
> on the outstanding issues.
Well, one thing I'm trying to fix is that it is not currently very
rewarding as a TC member to try to work on these issues. Most of the
discussions get bogged down in details, design of resolutions by
committee, and other problems.
TC members are forever voting for Further Discussion. We need to end
that and one way to do it is to provide a presumption that we'll
accept the Rapporteur's report.
Ian.
Reply to: