Re: Technical committee workflow
Raphael Hertzog writes ("Re: Technical committee workflow"):
> On Sat, 10 Jan 2009, Ian Jackson wrote:
> > Here's a first draft of the procedural resolution. Sorry it's so long
> > but I couldn't see how to make it shorter.
>
> It looks mostly fine. Two remarks however:
>
> - the explicit queue handling seems needlessly bureaucratic, sharing tasks
> is rarely problematic in my experience (giving up a task to someone else
> interested is easy).
I'm hoping that there will be some competition for tasks. As I have
described the system, _giving_ a task might be easy but _taking_ one
would be hard and why would the current taskholder give it up ?
Competition needs to be managed, with explicit rules. I agree it's
rather bureaucratic but I couldn't think of a better way of doing it
that traded off the desire to pick active and fast-responding TC
members against the desire to spread the power around. The system
I've proposed takes a lot of words to write down but not many to
actually implement: you can just cut-and-paste the queue from the
previous Rapporteur's email.
Round robin is not good enough and requires a list to be maintained
anyway. We could make a rule forbidding any one TC member from
claiming more than 1/nth of the items (eg, not more than 2 out of the
last 5) but that leaves open the possibility that a TC member who
always reads email once a day at a particular time could easily be
entirely deprived.
> - I don't understand your point 5. If a TC member disagree, he likely
> followed the discussions and should be able to immediately propose an
> alternative report instead of proposing to appoint himself as new
> rapporteur.
Part of the point is to concentrate the TC workload for an issue in a
single Rapporteur. That means that other TC members need to feel free
to let the Rapporteur get on with the discussion. One conclusion from
this is that the discussion needs to be somewhere other than the TC
list. Another conclusion is that TC members who don't follow the
Rapporteur's discussion in detail need to be given a proper chance to
prepare a response when it comes to the vote.
If a TC member is only supposed to object if they've been following
the discussion on -devel or wherever and have developed a position of
their own, then TC members who do not want to lose their voice (and
function) entirely will need to pay complete and detailed attention to
every such discussion.
So I'm trying on the one hand to set a reasonably high threshold: the
TC member should disagree with the chief substance of the decision,
and not just pick at details, and should be prepared to do some
significant work. And on the other hand I'm trying to allow a TC
member to make the decision to object relatively quickly even if they
haven't prepared a complete response to the issues in detail - indeed,
even if the first time they discover that the Rapporteur has gone off
in what seems to them to be quite the wrong direction, is when they
read the Report.
Ian.
Reply to: