>>>>> On Mon, 10 Apr 2023, Robin H Johnson wrote: > Mostly looks good to me, some discussion/improvements below. >> Author: Grant Goodyear , >> Ciaran McCreesh > Nit: I think this needs updates about who significant authors of new > revisions where. The only text passage that's more than a single sentence is [1]. It originates from a council summary from 2007 [2]. AFAICS kingtaco chaired that meeting, but vapier (CCing him) committed the summary. @robbat2: I also see that you participated in that meeting, do you remember who the author of that text was? The other changes are small, and originate from meeting logs and mailing list discussions. I am happy to add anyone who can claim authorship for them with a straight face. (I for my part won't, since my work was mostly editorial.) >> Version: 2 > Nit: Version needs to be incremented. Yes, Version and Post-History, and already committed [3]. >> +Updates to this document (other than editorial changes) require a vote >> +of all developers. The vote passes if the ratio of positive to negative >> +votes is at least 2:1, and if the number of positive votes is at least >> +1/4 of the number of eligible voters. > 1. This should probably describe how an all-developer vote is quorate, > because I don't think that's codified anywhere (and if it IS already > codified, it should referenced here). That's what I was trying to do with the clause "number of positive votes is at least 1/4 of the number of eligible voters." > 2. I think this would be clearer formatted as a list: > === > The vote passes if all of the following are satisfied; > - Ratio of positive to negative votes is at least 2:1 > - The number of positive votes is at least 1/4 of the number of eligible > voters. > - A majority (50% + 1) of developers voted. > === Let's first discuss these ratios, then how to format them. I also think that we would want a quorum only for positive votes, not for total votes, because with the latter a negative vote could make a motion pass. (Example: 200 eligible voters, 75 yes votes, 25 no votes => motion does not pass. With one additional no vote it would pass. This violates the monotonicity criterion [4].) >> + * It should have at least one lead, and the leads are selected by >> + the members of the project. This selection should occur at least >> + once every 12 months, and may occur at any time. Any member can >> + demand a lead election if the last election was more than >> + 12 months ago. > Should consequences of not holding an election when demanded be covered > here? I don't think that we need to mention such details here. It would be escalated in the usual way via ComRel, I guess. >> + * Whenever a member of the council loses their position (the reason >> + is irrelevant; e.g. they resign or they are booted for slacking), >> + then the next person in line from the previous council election >> + is offered the position. If they accept and the current council >> + unanimously accepts the new person, they get the position. >> + Otherwise, it is offered to the next person in line, and so forth. >> + If the council does not accept that person, then a new election is >> + held to choose a new member. The new member gets a 'reduced' term >> + so that the yearly elections still elect a full group. > Two questions for this section: > 1) Nit: In the case of tied ranked candidates that would be next in line, how > are they chosen? E.g. in the council-202106 election [A] there was a tie > between slyfox & whissi, as well as lu_zero as zx2c4. That's the same problem as for a tied 7th place in a council election, and we don't have a solution for that either. (In fact, there was a tie between ssuominen and myself in 2008-12, and we were able to solve it amicably [5].) > 2) Nit: Not likely to have an actual effect on the outcome due to the > over-supply of candidates at this time, but should the selection go past > the "_reopen_nominations" meta-candidate? I think it is obvious that it cannot. >> * 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. >> + is then reset from that point. Any such meeting must dissolve >> + immediately after the short roll call. > Can this be clarified to say that council members may informally discuss > the scheduled agenda, but the official votes cannot be held? I'd think > there might be cases where a discussion happens anyway, and then the > voting is moved to a bug. How about this instead: - is then reset from that point. + is then reset from that point. No substantive action can be + taken in any such meeting. Ulrich > [A] https://projects.gentoo.org/elections/council/2021/council-202106-results.txt [1] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=7d642173b0b05a0ebb3e142298a229cfcea8ba81 [2] https://projects.gentoo.org/council/meeting-logs/20070208-summary.txt [3] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=4d633cde224b5879a3e6f6fa7030165b3605cfa0 [4] https://en.wikipedia.org/wiki/Monotonicity_criterion [5] https://archives.gentoo.org/gentoo-dev/message/3cf357b8b433b37fd7cd85fa6a22df61