[gentoo-dev] Re: A Little Council Reform Anyone?

[Duncan]

Tobias Scherbaum <dertobi123@g.o> posted
1246546445.6186.33.camel@××××××××××××××××.de, excerpted below, on  Thu, 02
Jul 2009 16:54:05 +0200:

> Ned Ludd wrote:
>> I'd like to see the dev body have a year-round voice in the council.
>> Either via quick votes year-round on topics or simply by having
>> discussion in the channel.

> What I'd like to see for sure is a formal rule on who can decide to
> modify or change parts of glep 39. As it's the council's constitution
> somehow, we have two options from my pov (besides that a former council
> did decide the council itself can change it's rules): - a large majority
> (at least 5 out of 7) of council members needs to ack the change
> - changes to glep 39 require a vote with all developers participating
> and a large majority (2/3 or 3/4) needs to ack the suggested change

[posting to -devel only, as gmane has council as one-way, appropriately]

A vote of all developers is a bit steep, but maybe that's the intent.  As 
already mentioned, tho, it'd have to be a super-majority of those voting.

But the 5/7 supermajority rule for council to change its own constitution 
is a really good idea, IMO.  That's a 71% supermajority, and should be 
enough, IMO.  I've always been uncomfortable with the simple majority 
changing its own constitution or bylaws idea, Gentoo council or 
elsewhere.  It's just too unstable for the constitutional level.

>> An EAPI review committee could work well also. As long as we could get
>> non bias people in there.
>
> I was thinking about that for quite some time and as long as we get some
> non-biased people in there we should try that as well.

IMO, the "official PM implementation required before final approval" 
serves well enough as a practical cap on things, there.  As long as that 
is understood, and council approves a recommendation, then stamps the 
final spec when implemented, an EAPI committee can't go entirely 
renegade, no matter who's on it.

Plus, the committee approach was effectively what we did for EAPI-3 
already, except that arguably council was too hands-on, and more of the 
debate happened on the dev list and on council than was perhaps 
appropriate.

We already have a list for EAPI/PMS discussion, and I believe 
announcements and proposals can be made to dev (and/or council) lists 
with followups set to dev, for discussion.  If we simply use what we have 
and follow that rule, those interested enough to debate it there, 
effectively form the committee, regardless of whether there's an official 
one or not.

What remains, then, would be for the council to choose a spokeperson to 
keep them informed of updates and present the details.  That person 
should be seen as reasonably unbiased in ordered to make it work well for 
all sides, and they should be given a clear mandate from council that 
will effectively make them chairman of the committee, since they 
represent it, whether it's formalized or not.

Then let that spokesperson present the recommendation to council, 
preferably in written form, perhaps with a 10 minute verbal meeting time-
limit, with the details hashed out however it gets hashed out on the EAPI/
PMS list (council shouldn't need to interfere there, except by creating 
the spokesperson position, with said spokeperson serving at the pleasure 
of the council, so they can be removed and someone else appointed, if 
deemed necessary), with anyone from that list, or dev, or user, able to 
present an objection, again preferably in written form, with say a 2-
minute verbal argument meeting time-limit.

Then after the presentation, vote.  As with EAPI-3, do it in two stages, 
preliminary approval, then after implementation, final approval.  Total 
in-meeting time, x2: 10 minutes for spokesperson verbal presentation of 
written position, made available X days pre-meeting, 2 minutes x N people 
for independent support/disagree statements (say two people, 4 minutes), 
one minute for administrative (transitions, etc), 5 minutes at final 
approval for portage lead if he wishes, 5 minutes for voting.  Total 20 
minutes meeting time for preliminary approval, 25 minutes for final 
approval, 45 minutes over two meetings.  If it's voted down, it's sent 
back for further revisions, and won't be scheduled for another chance at 
council meeting approval for six months.

If the council members haven't done their homework and aren't ready to 
vote at the meeting, it reflects badly on them.  If the EAPI committee 
spokesperson doesn't have the written presentation ready in time, or 
can't manage his 10 minute verbal presentation, or if there's more than 
2-3 people lining up for their 2-minute slot to oppose it, it reflects 
badly on him, and the council should consider a different spokesperson.

Bottom line, IMO, the resources are already there, as are, to some 
extent, the rules.  All council needs to do is find and approve a single 
reasonably non-biased person to be a spokesperson, and enforce the rules 
on its own time, with everyone working together to enforce followups to 
the EAPI/PMS list for anything coming up on dev of that nature.

> Therefore: push Sunrise!

++  (I already posted agreement on prefix.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman