Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte
Russ Allbery writes ("Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte"):
> > * Explicitly being allowed to have private discussions on the subject
> > of who should maintain a particular package. The options should be:
> > - private discussions when we feel it appropriate
> > - private discussions only for appointments and maintainerships
> > - status quo
>
> This seems like a good idea, and I would tend to vote for private
> discussions when we feel it appropriate. Realistically, I don't see how
> one can stop people from having private conversations anyway when they
> know each other; it's just a natural thing for people to do, and those
> discussions happen in person at DebConf or in other media that isn't
> easily recorded even if we wanted to.
I think I agree. Perhaps we should offer that as the only option for
change.
How about this:
In Constitution 6.3 (wdiff -i):
3. Public [-discussion and-] decision-making.
[-Discussion,-]
Draft resolutions and amendments, and votes by members
of the committee, are made public on the Technical Committee public
discussion list. There is no separate secretary for the Committee.
Rationale:
On occasion we have been asked to decide on controversial matters
such as maintainership of packages. Allowing the TC to officially
hold private conversations will make it much easier for us to take
on a mediation role, which necessarily involves talking to each side
in private.
It will also make it easier for people to informally seek the advice
of the TC. On a number of occasions recently, enquirers have
emailed TC members' personal addreses to sound out our opinions.
This has worked well; however it is not clear that Constitution
permits it. This situation should be regularised.
Actual decisionmaking will still take place in public of course.
> > * Possibly increasing the maximum size of the committee. I would be
> > happy with 12, given the busy nature of the existing members.
>
> If there are people interested in helping drive things to resolution, that
> would be helpful, as we're not currently doing a stellar job on that
> front.
I still think we should formally allocate issues to TC members as they
come in.
Do you agree that the maximum size should be increased ? It would
look something like this perhaps:
In Constitution 6.2(1) and (2), increase the maximum size of the
Technical Committee from 8 to 12.
Rationale:
The TC is currently at its maximum size of 8. However TC members
tend to be very busy people so there is still something of a
shortage of effort. We would like to have the option to increase
the size of the committee to see if that helps get decisions made in
a more timely fashion.
> > * An advisory resolution which gives the project a way to formally
> > give us some guidance on how ready we should be to overrule
> > developers. A wording something like:
>
> > In the past the Technical Committee have been slow and reluctant
> > to overrule a maintainer unless all the members are absolutely
> > convinced that the maintainer's decision was wrong.
>
> > Option A: This is the correct approach.
>
> > Option B: TC members should be willing to vote to overrule
> > if they feel that the maintainer's decision was wrong;
> > the supermajority requirement is sufficient to guard
> > against overruling in questionable cases.
>
> Hm. That's interesting, yes. I have no idea what the outcome of that
> vote would be, and I'd be curious to see how it turned out. I think this
> should be a separate GR, though; I don't think it's really related to the
> above procedural issues.
Certainly, yes, but we should hold it concurrently.
Do you have any opinions about wording, rationale, etc. ?
Ian.
Reply to: