While working on my quizzes with idella4, we noticed a loophole in GLEP 39. Because there is no quorum requirement, a single council member could theoretically hold a meeting, without informing the other council members ahead of time, and wield the full power of the council on their own [1]: “Council decisions are by majority vote of those who show up (or their proxies).” With the collaboration of a GLEP editor, the rogue council member could even edit GLEPs [2]: “GLEP authors must have a GLEP editor commit their changes to the Wiki, as the GLEP namespace is restricted to GLEP editors in order to protect the integrity of the GLEPs. “Any major updates to GLEPs (that is, those that change the content of the GLEP rather than just fixing typos or adding small clarifications) should be approved by the Gentoo Council before being committed.” An example edit (with the rogue council member and collaborating GLEP editor), would be to remove the re-election clause from GLEP 39 [1]: “If any meeting has less than 50% attendance by council members, a new election for all places must be held within a month. The 'one year' is then reset from that point.” I propose amending that GLEP 39 rule to read: “If any meeting has less than 50% attendance by council members, a new election for all places must be held within a month. The 'one year' is then reset from that point. Any such meeting must dissolve immediately after the short roll call.” With an additional clause establishing the roll call: “Meetings must open with a roll call to establish which council members (or their appointed proxies) are present.” I'm not sure if we also need more explicit wording on how proxy appointments are to be confirmed. You wouldn't want to patch the GLEP just to have a bunch of folks appear claiming to be proxies, and hold their own council meeting without having any council members at all present ;). Perhaps that is the kind of thing that council members can argue afterwards. For example: “At the council meeting of 2014-08-16, ‘malory’ claimed to be my proxy. I did not appointed him to that position, so we must reconsider the results of that meeting as if ‘malory’ was not present.” Then a proxy-pretender meeting would have no valid council members (or valid proxies) present, and its only effect would be to trigger election inside a month. Of course, it's unlikely that a council member or proxy-pretender would actually take advantage of these loopholes. But if you're going to go through the trouble of having rules for the council, you might as well tighten them up ;). Thoughts? [1]: http://wiki.gentoo.org/wiki/GLEP:39#Specification [2]: http://wiki.gentoo.org/wiki/GLEP:1#Reporting_GLEP_Bugs.2C_or_Submitting_GLEP_Updates Reproducible: Didn't try
Well, this assumes a) bad faith on the part of the council, b) that a GLEP editor will go along with the plan (and until the Wiki move, anyone could edit and re-commit a GLEP anyway), c) that the community will accept any of this as valid. Even if you did have a one-member meeting, that member happened to be malicious and decided to screw around with GLEP 39 or something, a GLEP editor was sufficiently bribed (and for the record, I'm the only active GLEP editor, and I doubt people around here willing to meet my prices ;)), and the change were made, the community would undoubtedly say "nope" and proceed to ignore those changes as they re-elected the new council, especially since this change skipped the "get community approval" step of GLEP changes. Also, theoretically, your changes could let a malicious council member force a full reelection by having said secret meeting and not telling anyone. Adding "council members must tell each other about meetings" strikes me as rather silly as well. So...I'm inclined to say that this loophole is not worth the edit, but I'll CC council for their thoughts.
(In reply to Chris Reffett from comment #1) > Well, this assumes a) bad faith on the part of the council, Well, there are explicit rules for slacker council members ;). I agree that this is unlikely to come up, but if you have a rule about elections following a rump meeting, I think you should probably take the opportunity to invalidate any votes taken at that meeting. I'm not sure if there has ever been such a rump meeting historically (with good-faith council members). Maybe it's just easier to drop that clause entirely? For comparison, the foundation has quorum reqirements, both for the general members [1] and for the board [2], despite the fact that foundation members are also unlikely to be malicious. > c) that the community will accept any of this as valid. Even if … the > change were made, the community would undoubtedly say "nope" and proceed > to ignore those changes as they re-elected the new council, Ah. I'm not clear enough on the structure to know when the community at large is allowed to override/ignore the council. I'll probably leave discussion of possible actions to after we've decided whether or not this is a loophole we care about fixing. > especially since this change skipped the "get community approval" > step of GLEP changes. That wording is so vague ;). Maybe it's enough though. > Also, theoretically, your changes could let a > malicious council member force a full reelection by having said secret > meeting and not telling anyone. Adding "council members must tell each other > about meetings" strikes me as rather silly as well. I don't have a problem with this. If we have an extra election, we can just vote out the malicious people who forced if. [1]: https://www.gentoo.org/foundation/en/BylawsAdopted.xml#doc_chap3_sect8 [2]: https://www.gentoo.org/foundation/en/BylawsAdopted.xml#doc_chap5_sect8
(In reply to Chris Reffett from comment #1) > Well, this assumes a) bad faith on the part of the council, no it doesn't < b) that a GLEP editor will go along with the plan (and until the Wiki move, < anyone could > edit and re-commit a GLEP anyway), oooh! < c) that the community will accept any of this as valid. more ooooh! < Even if you did have a one-member meeting, that member > happened to be malicious and decided to screw around with GLEP 39 or > something, a GLEP editor was sufficiently bribed (and for the record, I'm > the only active GLEP editor, and I doubt people around here willing to meet > my prices ;)), and the change were made, the community would undoubtedly say > "nope" and proceed to ignore those changes as they re-elected the new > council, especially since this change skipped the "get community approval" > step of GLEP changes. Also, theoretically, your changes could let a > malicious council member force a full reelection by having said secret > meeting and not telling anyone. Adding "council members must tell each other > about meetings" strikes me as rather silly as well. So...I'm inclined to say > that this loophole is not worth the edit, \ I'm not < but I'll CC council for their thoughts. Good. No idea where you drummed up those assumptions from creffett, but they don't have a good look. Most any organization in at least the Western world has a builtin rule that Committees of authority require a quorum to supply a minimum standard of representation by elected members which prevents things like passing decisions by a 'stacked' subset of members. What this is is more than likely a simple oversight by those who wrote that GLEP back in the day, possibly because they thought it silly to 'state the bleedin' obvious' and subsequently never did! To require a quorum is not a presumption of badness, it's a form of ensuring goodness. What it means is that an undetermined % of more members of the Council MAY HAVE HAD a death in their nuclear family, annual leave in an internet free zone, or they all had acute concurrent bouts of slackerness, or mixtures of all the above. Think of it as a 'tidy up' like we do in ebuilds.
2008-05-15
GLEP 39 says that there must be new elections if "any meeting has less than 50% attendance by council members". The understanding is that this 50% attendance is also the necessary quorum for taking any decisions. Please also note that it explicitly says "council members" which doesn't include proxies. We have exactly one precedent for this situation, namely the 2008-05-15 council meeting. They didn't take any decisions then.
A few thoughts. The Council isn't a legal entity at all. Nobody has a legal obligation to obey them, nobody can sue them other than as individuals, and they can't sue anybody other than as individuals. That is what the Trustees are for. I think it is better to keep the formalities around the Council minimized as a result. Its purpose is to settle technical questions and it works because developers respect the leadership of its members, having been chosen by the developer community. I don't personally care for the slacker rule. Developers shouldn't be electing slackers to the council, and creating a rule that a council member has to say "here" sometime during the meeting does not fix any problems caused by disengaged council members. But, it is a rule and I'll follow it. If one council member calls a secret meeting and proclaims some new truth, then the rest of us will just ignore it and as a community we'll just have to deal with it, probably by holding new elections or something, with the majority of sensible council members continuing to operate in the meantime. If some council member pings infra and tells them that they just had a secret meeting and half the devs are to have cvs access removed, they're just going to escalate and do the sensible thing. From a legal standpoint, the only organization that really governs Gentoo is the Foundation/Trustees (setting aside the e.V. to simplify things). Legally they're the ones that control the trademarks/copyright/etc, and thus they have the legal means to have gentoo.org say whatever it is supposed to say, control who can log into Gentoo-owned servers, and so on. Generally speaking it is better that they don't get involved in day-to-day technical matters, but if for some reason there were some kind of major fork/etc that is where the legal authority resides. However, as we've seen with things like MySQL, XFree86, OpenOffice and so on owning a bunch of IP/servers doesn't really give anybody the final word in FOSS. So, my advice is that with the Council we should keep things simple. By all means we should have basic rules that govern 90% of the situations that come up so that we are all agreed on how we want the Council to operate. However, having a 47-page charter that deals with every contingency just isn't necessary. Heck, our Foundation charter isn't completely devoid of loopholes and that is a legal entity - it works well enough as is the case for most documents of this type. The reality is that if a situation with the Foundation goes to court and some specific situation isn't documented in the rules, courts will apply precedent and common sense to generally arrive at a reasonable result, and that usually means that one-man coups don't work.
(In reply to Ulrich Müller from comment #5) > GLEP 39 says that there must be new elections if "any meeting has less than > 50% attendance by council members". The understanding is that this 50% > attendance is also the necessary quorum for taking any decisions. Sounds like a good policy to me. I think we should make this explicit, especially since it's just a single additional sentence. > We have exactly one precedent for this situation, namely the 2008-05-15 > council meeting. They didn't take any decisions then. Ah, thanks for the pointer. They also spent 20 minutes discussing what to do in this situation and attempting to interpret the GLEP and spawned a long thread on gentoo-dev [1]. Perhaps we should record any resulting consensus so future councils don't have to rehash the issue? [1]: http://thread.gmane.org/gmane.linux.gentoo.council/147/focus=148
(In reply to W. Trevor King from comment #7) > Perhaps we should record any resulting consensus so future councils don't have to rehash the issue? > > > [1]: http://thread.gmane.org/gmane.linux.gentoo.council/147/focus=148 After reading through that thread and associated messages, it looks like the consensus was “follow the GLEP wording and hold the elections” [1,2]. There was discussion about whether or not GLEPs could be retroactively amended, but I found no consensus on that subject. Personally, I think you should work from within the system to change any policies for the future. If you get blindsided by a shortcoming in the existing policies, you should take your lumps, and then take the appropriate action to amend that policy before it hits you again. Despite apparent consensus that the forced re-election was too harsh, it seems that the council took no action to remove the 50% clause (because we still have it). All of this is sort of besides the point for this discussion though, which is about whether we need a quorum clause. At least Ferris McCormick and Ned Ludd felt that it was a non-meeting [3,4], and I didn't see any push-back, so it would be nice to make that official. It would certainly be easier to do that than it would be to figure out a quorum-less definition for “meeting”, or to rehash the issue the next time we have a rump meeting. [1]: http://thread.gmane.org/gmane.linux.gentoo.council/155/focus=176 [2]: http://thread.gmane.org/gmane.linux.gentoo.council/184 [3]: http://article.gmane.org/gmane.linux.gentoo.project/337 [4]: http://article.gmane.org/gmane.linux.gentoo.council/162
The problem with amending is that GLEP 39 is not a normal GLEP. The rules that govern our projects and council were decided upon in a vote of all developers. The GLEP process was chosen at the time only as a convenient means of publishing the result (I guess that's also the reason why GLEP 39 has only "informational" status). Therefore it is questionable if the usual rules for updating/amending apply to GLEP 39.
(In reply to Ulrich Müller from comment #9) > The problem with amending is that GLEP 39 is not a normal GLEP. The rules > that govern our projects and council were decided upon in a vote of all > developers. The GLEP process was chosen at the time only as a convenient > means of publishing the result (I guess that's also the reason why GLEP 39 > has only "informational" status). Therefore it is questionable if the usual > rules for updating/amending apply to GLEP 39. This came up a few times during the mailing list discussion as well [1]. The two positions I remeber were Ciaran's [2]: “Revisions to the GLEP pretty much require a global vote… It wasn't written or approved as a GLEP, but it's listed as a GLEP for historical purposes and to make it easy to find.” and William's [3]: “So IMHO once voted upon and a council was created to decided upon global matters. Individual power has been given up, and passed on from developers and TLP managers, to council members.” As far as I can tell, no consensus was reached on this issue. However, the GLEP was ammended on 2009-02-09 [4]. I'm trying to figure out if that change was approved by a council vote or by a member-wide vote. As for the “informational” status, the specs say [5]: “An Informational GLEP provides general guidelines or information to the Gentoo Linux community, but does not propose a new feature. Informational GLEPs do not necessarily represent a Gentoo Linux community consensus or recommendation, so users and implementors are free to ignore Informational GLEPs or follow their advice.” That doesn't sound like it has anything to do with the change-approval procedure. It *does* sound like the council is free to ignore the whole GLEP if they want. In that case, I'm not sure I see the point of any of the finer details (slacker clauses, proxies, etc.). [1]: http://thread.gmane.org/gmane.linux.gentoo.council/147/focus=148 [2]: http://article.gmane.org/gmane.linux.gentoo.project/333 He restated this position a number of other times in the thread. [3]: http://article.gmane.org/gmane.linux.gentoo.project/371 This position was also held explicitly by a number of other people, and implied by comments from several more. [4]: http://wiki.gentoo.org/wiki/GLEP:39#Status [5]: http://wiki.gentoo.org/wiki/GLEP:1#Kinds_of_GLEPs
(In reply to W. Trevor King from comment #10) > As far as I can tell, no consensus was reached on this issue. However, the > GLEP was ammended on 2009-02-09 [4]. I'm trying to figure out if that > change was approved by a council vote or by a member-wide vote. Still looking for the 2009 change, but here are some excerpts from the council logs: 2010-03-08 [x]: 21:07:51 <Calchan> scarabeus, since you joined us recently you might not rememebr that I was the one raising this issue at the beginning of our term 21:08:28 <Calchan> and the council decided that it couldn't change glep 39 on its own, which is silly because it had been done before 2010-05-17 [a]: 21:06:14 <Calchan> 2. Review of GLEP 39 overhaul propositions (30 minutes) … 21:07:59 <dertobi123> Calchan: put the proposed ballots up for review a week before voting starts and everyone is able to send in fixes … 21:24:46 <Calchan> second topic: http://archives.gentoo.org/gentoo-project/msg_76311b25ccb18fff4764955db55ad0ea.xml … 21:29:09 <Calchan> anybody else with a comment about this ballot? 21:29:48 <Calchan> let's switch to the next one then… 2011-08-09 [y]: Items proposed but not on the agenda: … * Council terms: overlapping 2-year terms… - Requires a full developer vote on changes to GLEP 39 so council approval is not relevant 2013-02-12 [z]: 21:40 <@ grobian> Calchan: wanna run for some changes to glep 39? :) … 21:46 < Calchan> WilliamH: I may blog about it, I've been slacking on this for about 3 years The closest we got to clarification was in 2010-05-17, with this proposal [b]. I haven't found if it was actually put to a vote (either by the council or by a global vote). [x]: http://www.gentoo.org/proj/en/council/meeting-logs/20100308.txt [a]: http://www.gentoo.org/proj/en/council/meeting-logs/20100517.txt [y]: http://www.gentoo.org/proj/en/council/meeting-logs/20110809-summary.txt [z]: http://www.gentoo.org/proj/en/council/meeting-logs/20130212.txt [b]: http://archives.gentoo.org/gentoo-project/msg_76311b25ccb18fff4764955db55ad0ea.xml
(In reply to W. Trevor King from comment #11) > Still looking for the 2009 change, but here are some excerpts from the > council logs: Ahh, here we go [1]: * Donnie asked for a clarification by the council members on whether they think a global dev vote is required to update GLEP39 or not. The council voted 5 yes and 1 no that the council can't change GLEP39 as it requires a full developer vote. it would be nice to encode that in the GLEP itself, so that we didn't have follow-up discussion like the 2011-08-09 caveat and 2013-02-12 GLEP-39-change proposal don't come up anymore? [1]: http://www.gentoo.org/proj/en/council/meeting-logs/20110715-summary.txt
(In reply to W. Trevor King from comment #12) > it would be nice to encode that in the GLEP itself, … But this is still somewhat tangential to my initial request for clarifying whether the council can make *any* decisions in a rump session. If GLEP 39 is off limits, the council still has other powers that a rump session can abuse.
Honestly, I could care less what those who created GLEP 39 intended when they created it. I care a great deal more how those who are contributing today feel about the matter (including those who have been around, and those who are new). So, if somebody wants to change GLEP 39 I'd suggest bringing up the proposed changes on the list and see how everybody feels about them. My biggest issue with the special treatment of GLEP 39 is that because nobody wants to claim to have the authority to change it, we don't change it even when it makes sense to do so. If anything I'd like to remove the slacker clause. I advocated that before I was on the Council, but I don't think a majority really supported that position. If that is still the case, then I doubt we'll end up removing it. My biggest issue with that clause is we have cases where the Council wants to meet more often but avoids doing it because we aren't sure what triggers it and nobody wants to deal with an election. There was a desire to just have an administrative meeting to schedule times, coordinate chairs, etc this year and we ended up putting it off because not everybody would be able to make it, and nobody wanted to have the Council disbanded a week after the election due to a clause that clearly was never intended to apply to things like organizing the calendar...
(In reply to Richard Freeman from comment #14) > My biggest issue with the special treatment of GLEP 39 is that because > nobody wants to claim to have the authority to change it, we don't change it > even when it makes sense to do so. I've factored this change-authority issue out into #520156, so we can stay focused on the rump/quorum issue here.
Removing council from CC, as decided in today's council meeting.
Does anyone wish to champion this change? If not, I'm going to close the bug due to no activity.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/glep.git/commit/?id=29bfaccbe91395059dacf47dfa9759283301aed2 commit 29bfaccbe91395059dacf47dfa9759283301aed2 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2022-11-10 12:06:12 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2023-04-15 11:58:19 +0000 glep-0039: An inquorate council meeting cannot take substantive action Bug: https://bugs.gentoo.org/520074 Signed-off-by: Ulrich Müller <ulm@gentoo.org> glep-0039.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
