Tobias Scherbaum <dertobi...@gentoo.org> posted 1246546445.6186.33.ca...@homer.ob.libexec.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
