Re: Tech ctte tweaks
On 2/4/06, Anthony Towns <aj@azure.humbug.org.au> wrote:
> (1) Rotating the tech ctte chair
>
> Changing chairs every two months would mean everyone would be chair over
> the course of the year; helping ensure that we notice people who aren't
> active in a timely manner, and distributing the load a bit more fairly.
>
> I propose we do this, and for concreteness propose the following rotation:
>
> - Feb 14th Ian Jackson
> Feb 15th - Mar 31st Steve Langasek
> Apr 1st - May 31st Bdale Garbee
> Jun 1st - Jul 31st Anthony Towns
> Aug 1st - Sep 30th Raul Miller
> Oct 1st - Nov 30th Andreas Barth
> Dec 1st - Jan 31st Ian Jackson
That could work, though it's odd that Steve gets a shorter time
in the chair than others.
Also, the handoffs are going to be interesting -- then again, the
whole "rotating chair" thing is going to be interesting.
> (2) Requiring an implementation of proposals
>
> The md5sum "decision" is still languishing after a year and a half, and
...
> So I propose we establish a rule that we won't make decisions on issues
> that aren't ready for an immediate NMU when we make that decision.
I don't know that we need to make a rule about this so much as
advertise a guideline.
> (3) Advisory opinions from the chair
...
> So I propose we establish that our procedure in addressing issues is
> for the chair to quickly issue an initial opinion; and to only vote on
> issues when an official ruling is needed (eg, to overrule a maintainer)
> or when members of the tech ctte disagree.
I'm not sure about this.
If we need someone to shoot from the hip, the package maintainer
seems just as good as anyone. The point of the Technical Committee
is to provide a bailout when people disagree with that kind of thing.
Usually, that means that there's something seriously wrong -- some
critical piece of information isn't known, or some compatibility
issue means that more than one answer is a good answer and that
all of the good answers are bad answers...
I think I understand where you're coming from on this, but I'm
still uncomfortable with this solution.
But let's say we implemented this: what would do you think would
be different as a result?
If your primary concern is inactivity, how about something more
aimed at inactivity: Allow the chairman to propose a solution
in some clear and formal manner, and if no one comments on
it for a week then it becomes the defacto solution for that issue
(this might require a GR to become valid for the project as
a whole).
Thanks,
--
Raul
Reply to: