I forgot to include it, but the "Fast Track" process should remain as-is: Any FESCo member may request a proposal be considered "Fast Track", and it automatically gets approved immediately if it receives +7 without any -1 votes. Any -1 vote removes the Fast Track request.

2 initial comments:

1. We had in our process a '15 minute' rule. This was enacted to prevent one or a few members from just keeping discussing until everyone else gave up. Do we want to keep that?

2. what happens when people don't vote in ticket or meeting?

@sgallagh So the only time a 0 vote on the ticket matters is if the proposal is voted on during the meeting and the person who voted 0 can't attend. Which in that case means the vote would be treated like a 0 vote during the meeting.

@sgallagh So the only time a 0 vote on the ticket matters is if the proposal is voted on during the meeting and the person who voted 0 can't attend. Which in that case means the vote would be treated like a 0 vote during the meeting.

Correct.

2 initial comments:

1. We had in our process a '15 minute' rule. This was enacted to prevent one or a few members from just keeping discussing until everyone else gave up. Do we want to keep that?

Given that we have never really honored that rule, it seems pointless to include it.

1. what happens when people don't vote in ticket or meeting?

I think I covered that: lack of meeting votes reverts to the ticket process. The ticket process times out after two weeks with an auto-rejection.

I guess the one case that's not covered is that of a bad actor voting -1 forever to keep restarting the process and sending it back to a meeting, but I can't really see anyone on FESCo behaving in such a manner.

The 15min rule was used extensively in the past. Just because we haven't really used it much recently doesn't mean it wasn't used.
I suppose we can drop it for now and revisit it if we want it back.

Minor edit, the line "If a vote in the meeting achieves a 51% majority against a proposal (accounting for any explicit 0 votes), that proposal is accepted." was meant to read "If a vote in the meeting achieves a 51% majority against a proposal (accounting for any explicit 0 votes), that proposal is rejected." and has been updated in the proposal summary.

Suggestions:

It will therefore be beholden to the rules below.

Strike this sentence. "Rules below" is confusing, because the next paragraph (right below) talks about something unrelated.

If not, the proposal is considered rejected and the status quo will be maintained. The submitter may at this time make a new proposal which will restart this process.

I think that instead this should trigger automatic addition to the meeting agenda. I think this is what we'd do anyway and it seem much more user-friendly to discuss the proposal during a meeting than to just reject it.

If this is done, the discussion in the meeting is ended until the ticket voting has resolved or triggered another meeting.

I don't understand what "discussing in the meeting is ended" means. What if somebody makes a comment on the topic in the meeting?

Note that there is no provision for a 0 vote in ticket-only votes. Any such votes will be ignored. See below for the lone exception.

This says "no provision" but immediately proceeds to describe a provision. I think it'd be better to write this as "The only effect of 0 vote in a ticket is that it is retained for a vote in the meeting if the voter cannot attend."

The 15 minute rule should be a meeting procedure, not in the voting policy.

There's a bug in the extra week part when strictly interpreted

If there are insufficient +1 votes at the end of one week, one additional week will be granted. At the end of this period, if there is at least one +1 vote, the proposal is approved.

To exploit:

1. A proposal gets a single +1 in the first week
2. The vote is extended for another week
3. The proposal gets two - 1 votes
4. The vote is now (+1,-2), but it still passes

I'm sure that's not the intent, so it could use some clarification.

A couple of general points:

1. The language in this policy could stand to be plainer. I understand the urge to write in a formal, "legalese" style when writing rules. However, I suspect that's the source of the bug in my previous comment as well as some other wording issues pointed out by others. Also, plain English will likely be easier to understand for contributors who don't speak English as a first language.
2. I don't see a devel thread on this, although perhaps I missed it. Historically, FESCo has preferred proposals receive some kind of discussion on devel prior to FESCo consideration. I haven't been following the meeting logs, so the context for this proposal is not clear to me, but in general the historical practice is a good rule. I the current optics situation, we should avoid people finding out about a proposed change to the voting rules a few hours before the meeting where they could be approved. (I know that this isn't a substantial change, but there are probably two dozen people in the world who are intimately familiar with FESCo's rules and nine of them will be voting on this)

Suggestions:

It will therefore be beholden to the rules below.

Strike this sentence. "Rules below" is confusing, because the next paragraph (right below) talks about something unrelated.

Sure, that seems reasonable. It made more sense before I reorganized the draft.

If not, the proposal is considered rejected and the status quo will be maintained. The submitter may at this time make a new proposal which will restart this process.

I think that instead this should trigger automatic addition to the meeting agenda. I think this is what we'd do anyway and it seem much more user-friendly to discuss the proposal during a meeting than to just reject it.

OK, there's a couple sentences missing in a reorganization that I think would have helped here. First, any FESCo member can nominate a ticket for meeting discussion for any reason. Second, this behavior is somewhat intentional; it's essentially providing us with a passive veto. Lastly: this is in fact implicit in the current policy. I was making it explicit.

I also just realized I missed replicating "Proposals that receive a unanimous vote are immediately considered approved or rejected as appropriate, independent of fast-track status." which was an oversight. I'll add that and other corrections in a new draft once I finish reading these comments.

If this is done, the discussion in the meeting is ended until the ticket voting has resolved or triggered another meeting.

I don't understand what "discussing in the meeting is ended" means. What if somebody makes a comment on the topic in the meeting?

They are asked to take it to the ticket. This is essentially us electing not to waste additional time in the meeting. After we've ended the discussion, we want to avoid restarting it without another period of ticket/list discussion.

Note that there is no provision for a 0 vote in ticket-only votes. Any such votes will be ignored. See below for the lone exception.

This says "no provision" but immediately proceeds to describe a provision. I think it'd be better to write this as "The only effect of 0 vote in a ticket is that it is retained for a vote in the meeting if the voter cannot attend."

Another casualty of my reorganizing the structure. I agree completely that your phrasing is better.

There's a bug in the extra week part when strictly interpreted

If there are insufficient +1 votes at the end of one week, one additional week will be granted. At the end of this period, if there is at least one +1 vote, the proposal is approved.

To exploit:

1. A proposal gets a single +1 in the first week
2. The vote is extended for another week
3. The proposal gets two - 1 votes
4. The vote is now (+1,-2), but it still passes

I'm sure that's not the intent, so it could use some clarification.

No bug: "-1 I am opposed to the proposal as currently written. This topic must be discussed live in a meeting."

A couple of general points:

1. The language in this policy could stand to be plainer. I understand the urge to write in a formal, "legalese" style when writing rules. However, I suspect that's the source of the bug in my previous comment as well as some other wording issues pointed out by others. Also, plain English will likely be easier to understand for contributors who don't speak English as a first language.

I'm going to put a second draft out today; I'll see what I can do there.

1. I don't see a devel thread on this, although perhaps I missed it. Historically, FESCo has preferred proposals receive some kind of discussion on devel prior to FESCo consideration. I haven't been following the meeting logs, so the context for this proposal is not clear to me, but in general the historical practice is a good rule. I the current optics situation, we should avoid people finding out about a proposed change to the voting rules a few hours before the meeting where they could be approved. (I know that this isn't a substantial change, but there are probably two dozen people in the world who are intimately familiar with FESCo's rules and nine of them will be voting on this)

Given that the purpose here is to reduce ambiguity in the current approach and only makes one real deviation (the ability to explicitly not vote), I don't think it likely to have much impact, but you're right: for optics we should probably require at least a week between when this gets approved and when it goes into effect in case there is backlash.

Second Draft

I've highlighted the changed portions from the first draft for ease of review.

Ticket Votes (Preferred)

Once a formal proposal is made in a ticket, voting will proceed. A Change ticket is assumed to be a a formal proposal upon creation.

An official vote in a ticket must be one of +1, -1 as defined herein:

• +1 I am in favor of the proposal as currently written.
• 0 I am electing to remove myself from the list of eligible voters. This has no effect unless the ticket votes are used for a meeting vote.
• -1 I am opposed to the proposal as currently written. This topic must be discussed live in a meeting.

At the end of one week, if a ticket has at least 3 votes of +1 and no votes of -1, it is approved and may proceed with implementation. If there is at least one -1 vote, the ticket must be added to the upcoming meeting agenda and subject to the Meeting Votes rules.

If there are insufficient +1 votes at the end of one week, one additional week will be granted. At the end of this period, if there is at least one +1 vote and no votes of -1, the proposal is approved. If there is at least one -1 vote, the ticket must be added to the upcoming meeting agenda and subject to the Meeting Votes rules. If there are no votes at all, the proposal is considered rejected and the status quo will be maintained. The submitter may at this time make a new proposal which will restart this process.

Meeting votes

At the meeting, a reasonable amount of time must be given for discussion. Once a proposal is made in the chat, the vote will be tallied as follows:

A proposal must achieve a majority (at least 51%) of +1 votes from eligible voters. Votes must be one of +1, 0 or -1 as defined herein:

• +1 I am in favor of the proposal as currently written.
• 0 I am electing to remove myself from the list of eligible voters. This reduces the denominator of the fraction required to achieve the 51% majority. In effect, I am agreeing to vote with the remaining majority, whatever they decide.
• -1 I am opposed to the proposal as currently written.

Any eligible voter that cannot attend the meeting is assumed to retain any vote that they have made in the ticket prior to the meeting. Note that this does not apply to new proposals made in the meeting, with the exception of simple clarification edits.

If a vote in the meeting achieves a 51% majority in favor of a proposal (accounting for any explicit 0 votes), that proposal is accepted.

If a vote in the meeting achieves a 51% majority against a proposal (accounting for any explicit 0 votes), that proposal is rejected.

If a proposal in a meeting fails to achieve a majority either for or against, the FESCo members present must either:

• Present a new proposal, restarting the meeting voting process.
• Return the proposal to the ticket, restarting the ticket voting process above. All votes made in the meeting will be transferred to the ticket (Note: negative votes recorded in this way do trigger discussion at the next meeting as normal). Once FESCo agrees to return the proposal to the ticket, all discussion in the current meeting on the topic is ended until that ticket vote has concluded with either a decision or is transferred to another meeting.

This was discussed in today's FESCo meeting:
- A second draft was posted today. We'll continue the discussion in the ticket. (zbyszek, 17:23:01)
- ACTION: zbyszek to send a heads-up to fedora-devel mailing list. (zbyszek, 17:28:28)
→ https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/R4523423JD542EJI2WLDQX2YNNFAU3KH/

What does the following mean?

Once a proposal is made in the chat, the vote will be tallied as follows:

which chat is this? IRC meeting? IRC/Matrix channel? Or is that meant to be 'Once a proposal is made as a ticket..' ?

More comments:

+1 I am in favor of the proposal as currently written.

Please add " — " in "+1 — I am" in all bullet points.

Any eligible voter that cannot attend the meeting is assumed to retain any vote that they have made in the ticket prior to the meeting.

I think it'd simplify matters if we just allowed existing votes to stand. This way we don't have everyone say that they retain their vote. The chair can even prepare a tally beforehand to streamline the process.

Proposed revision: "Any eligible voter is assumed to retain the last vote that they made in the ticket prior to the meeting."

make a new proposal which will restart this process.

If a new proposal is made, the proposal would probably need to go through the whole Change proposal process. But "this process" implies the voting process. So maybe say "… which will be processed following the usual rules." ?

(I unset meeting because of the resolution in the last meeting: We'll continue the discussion in the ticket. I don't think there's anything new to warrant the label.)

@sgallagh can you make an update for the last comments? I think the discussion has died down, so I expect we'd be able to vote and approve.

Third Draft

I've highlighted the changed portions from the second draft for ease of review.

Ticket Votes (Preferred)

Once a formal proposal is made in a ticket, voting will proceed. A Change ticket is assumed to be a a formal proposal upon creation.

An official vote in a ticket must be one of +1, -1 as defined herein:

• +1 — I am in favor of the proposal as currently written.
• 0 — I am electing to remove myself from the list of eligible voters. This has no effect unless the ticket votes are used for a meeting vote.
• -1 — I am opposed to the proposal as currently written. This topic must be discussed live in a meeting.

At the end of one week, if a ticket has at least 3 votes of +1 and no votes of -1, it is approved and may proceed with implementation. If there is at least one -1 vote, the ticket must be added to the upcoming meeting agenda and subject to the Meeting Votes rules.

If there are insufficient +1 votes at the end of one week, one additional week will be granted. At the end of this period, if there is at least one +1 vote and no votes of -1, the proposal is approved. If there is at least one -1 vote, the ticket must be added to the upcoming meeting agenda and subject to the Meeting Votes rules. If there are no votes at all, the proposal is considered rejected and the status quo will be maintained. The submitter may at this time make a new proposal which will be processed following the usual rules.

Meeting votes

At the meeting, a reasonable amount of time must be given for discussion. Once a proposal is made in the meeting, the vote will be tallied as follows:

A proposal must achieve a majority (at least 51%) of +1 votes from eligible voters. Votes must be one of +1, 0 or -1 as defined herein:

• +1 — I am in favor of the proposal as currently written.
• 0 — I am electing to remove myself from the list of eligible voters. This reduces the denominator of the fraction required to achieve the 51% majority. In effect, I am agreeing to vote with the remaining majority, whatever they decide.
• -1 — I am opposed to the proposal as currently written.

Any eligible voter is assumed to retain the last vote that they made in the ticket prior to the meeting. Note that this does not apply to new proposals made in the meeting, with the exception of simple clarification edits.

If a vote in the meeting achieves a 51% majority in favor of a proposal (accounting for any explicit 0 votes), that proposal is accepted.

If a vote in the meeting achieves a 51% majority against a proposal (accounting for any explicit 0 votes), that proposal is rejected.

If a proposal in a meeting fails to achieve a majority either for or against, the FESCo members present must either:

• Present a new proposal, restarting the meeting voting process.
• Return the proposal to the ticket, restarting the ticket voting process above. All votes made in the meeting will be transferred to the ticket (Note: negative votes recorded in this way do trigger discussion at the next meeting as normal). Once FESCo agrees to return the proposal to the ticket, all discussion in the current meeting on the topic is ended until that ticket vote has concluded with either a decision or is transferred to another meeting.

Looks great.

+1

Thanks for putting that together @sgallagh.

+1

+1

ok, I can be +1 to that version

Any eligible voter is assumed to retain the last vote that they made in the ticket prior to the meeting. Note that this does not apply to new proposals made in the meeting, with the exception of simple clarification edits.

This should probably be clarified to also say that in-ticket votes also don't carry over to new proposals that were made in ticket, not only during a meeting.

Other than that, +1 to the third draft. Thanks for working on this, finally a better solution for those pesky 0 votes :)

This should probably be clarified to also say that in-ticket votes also don't carry over to new proposals that were made in ticket

At the end of one week, if a ticket has at least [...]

The text conflates tickets and proposals. We usually have just one proposal in a ticket, but not always. So I think the text should be edited to replace "ticket" with "proposal" in a few places. This would make this issue clearer.

The text conflates tickets and proposals. We usually have just one proposal in a ticket, but not always. So I think the text should be edited to replace "ticket" with "proposal" in a few places. This would make this issue clearer.

Patches welcome, because I'm not sure where you think this change needs to be made.

Any eligible voter is assumed to retain the last vote that they made in the ticket prior to the meeting. Note that this does not apply to new proposals made in the meeting, with the exception of simple clarification edits.

This should probably be clarified to also say that in-ticket votes also don't carry over to new proposals that were made in ticket, not only during a meeting.

So should I simply drop the "made in the meeting" phrasing there? So, new sentence "Note that this does not carry over to new proposals, with the exception of minor clarification edits."

Patches welcome, because I'm not sure where you think this change needs to be made.

Actually, I think only once spot needs to be changed:

At the end of one week, if a ~~ticket~~ proposal has at least 3 votes of +1 and no votes of -1, it is approved and ~~may proceed with implementation~~ implementation may proceed.

So should I simply drop the "made in the meeting" phrasing there?

I think so.

Fourth Draft

I've highlighted the changed portions from the third draft for ease of review.

Ticket Votes (Preferred)

Once a formal proposal is made in a ticket, voting will proceed. A Change ticket is assumed to be a a formal proposal upon creation.

An official vote in a ticket must be one of +1, -1 as defined herein:

• +1 — I am in favor of the proposal as currently written.
• 0 — I am electing to remove myself from the list of eligible voters. This has no effect unless the ticket votes are used for a meeting vote.
• -1 — I am opposed to the proposal as currently written. This topic must be discussed live in a meeting.

At the end of one week, if a proposal has at least 3 votes of +1 and no votes of -1, it is approved and may proceed with implementation. If there is at least one -1 vote, the ticket must be added to the upcoming meeting agenda and subject to the Meeting Votes rules.

If there are insufficient +1 votes at the end of one week, one additional week will be granted. At the end of this period, if there is at least one +1 vote and no votes of -1, the proposal is approved. If there is at least one -1 vote, the ticket must be added to the upcoming meeting agenda and subject to the Meeting Votes rules. If there are no votes at all, the proposal is considered rejected and the status quo will be maintained. The submitter may at this time make a new proposal which will be processed following the usual rules.

Meeting votes

At the meeting, a reasonable amount of time must be given for discussion. Once a proposal is made in the meeting, the vote will be tallied as follows:

A proposal must achieve a majority (at least 51%) of +1 votes from eligible voters. Votes must be one of +1, 0 or -1 as defined herein:

• +1 — I am in favor of the proposal as currently written.
• 0 — I am electing to remove myself from the list of eligible voters. This reduces the denominator of the fraction required to achieve the 51% majority. In effect, I am agreeing to vote with the remaining majority, whatever they decide.
• -1 — I am opposed to the proposal as currently written.

Any eligible voter is assumed to retain the last vote that they made in the ticket prior to the meeting. Note that this does not carry over to new proposals, with the exception of minor clarification edits.

If a vote in the meeting achieves a 51% majority in favor of a proposal (accounting for any explicit 0 votes), that proposal is accepted.

If a vote in the meeting achieves a 51% majority against a proposal (accounting for any explicit 0 votes), that proposal is rejected.

If a proposal in a meeting fails to achieve a majority either for or against, the FESCo members present must either:

• Present a new proposal, restarting the meeting voting process.
• Return the proposal to the ticket, restarting the ticket voting process above. All votes made in the meeting will be transferred to the ticket (Note: negative votes recorded in this way do trigger discussion at the next meeting as normal). Once FESCo agrees to return the proposal to the ticket, all discussion in the current meeting on the topic is ended until that ticket vote has concluded with either a decision or is transferred to another meeting.

+1 to the 4th draft

Still +1 ;)

An official vote in a ticket must be one of +1, -1 as defined herein:

And the list herein also has 0, which is confusing.

At the meeting, a reasonable amount of time must be given for discussion. Once a proposal is made in the meeting, the vote will be tallied as follows:

I suppose this assumes the quorum is met. If so, could we make it explicit in the proposal?

A proposal must achieve a majority (at least 51%) of +1 votes from eligible voters.

Who is an eligible voter? Is it any FESCo member who has not yet voted 0 in the ticket or this meeting? Or is it any such present FESCo membe? In other words, do FESCo members who have not voted in the ticket and are not present at the meeting (or are present but got distracted and did not cast any vote at all) count as 0 or not?

And, is there a minimal number of +1 voters on meeting, or if 4 out of 5 present FESCo members vote 0, they give the power to the 1 that remains?

An official vote in a ticket must be one of +1, -1 as defined herein:

And the list herein also has 0, which is confusing.

I'll fix that.

---

At the meeting, a reasonable amount of time must be given for discussion. Once a proposal is made in the meeting, the vote will be tallied as follows:

I suppose this assumes the quorum is met. If so, could we make it explicit in the proposal?

A proposal must achieve a majority (at least 51%) of +1 votes from eligible voters.

Who is an eligible voter? Is it any FESCo member who has not yet voted 0 in the ticket or this meeting? Or is it any such present FESCo membe? In other words, do FESCo members who have not voted in the ticket and are not present at the meeting (or are present but got distracted and did not cast any vote at all) count as 0 or not?

The definition of "eligible voters" seems to have been unclear it is intended to be "The set of all serving FESCo members who have not voted 0 on the proposal, regardless of their attendance in the meeting."

And, is there a minimal number of +1 voters on meeting, or if 4 out of 5 present FESCo members vote 0, they give the power to the 1 that remains?

If four present FESCo members vote 0, they have given the decision over to the majority vote of the four members not present plus the one who is. There is intentionally no provision in this proposal for an implicit 0 vote (meaning not casting a vote is intentionally not the same as voting 0).

Fifth Draft

I've highlighted the changed portions from the fourth draft for ease of review.

Ticket Votes (Preferred)

Once a formal proposal is made in a ticket, voting will proceed. A Change ticket is assumed to be a a formal proposal upon creation.

Eligible voters on FESCo tickets are all currently-serving members of FESCo.

An official vote in a ticket must be one of +1, 0, -1 as defined herein:

• +1 — I am in favor of the proposal as currently written.
• 0 — I am electing to remove myself from the list of eligible voters for this proposal. This has no effect unless the ticket votes are used for a meeting vote.
• -1 — I am opposed to the proposal as currently written. This topic must be discussed live in a meeting.

At the end of one week, if a proposal has at least 3 votes of +1 and no votes of -1 in the ticket, it is approved and may proceed with implementation. If there is at least one -1 vote, the ticket must be added to the upcoming meeting agenda and is subject to the Meeting Votes rules.

If there are insufficient +1 votes at the end of one week, one additional week will be granted. At the end of this period, if there is at least one +1 vote and no votes of -1, the proposal is approved. If there is at least one -1 vote, the ticket must be added to the upcoming meeting agenda and is subject to the Meeting Votes rules. If there are no votes at all, the proposal is considered rejected and the status quo will be maintained. The submitter may at this time make a new proposal which will be processed following the usual rules.

Meeting votes

Eligible voters on FESCo meetings are all currently-serving members of FESCo who have not explicitly voted 0 on a proposal.

At the meeting, a reasonable amount of time must be given for discussion. Once a proposal is made in the meeting, the vote will be tallied as follows:

A proposal must achieve a majority (at least 51%) of +1 votes from eligible voters, regardless of their attendance at the meeting. Votes must be one of +1, 0 or -1 as defined herein:

• +1 — I am in favor of the proposal as currently written.
• 0 — I am electing to remove myself from the list of eligible voters. This reduces the denominator of the fraction required to achieve the 51% majority. In effect, I am agreeing to vote with the remaining majority, whatever they decide.
• -1 — I am opposed to the proposal as currently written.

Any eligible voter is assumed to retain the last vote that they made in the ticket prior to the meeting. Note that this does not carry over to new proposals, with the exception of minor clarification edits.

If a vote in the meeting achieves a 51% majority in favor of a proposal (accounting for any explicit 0 votes), that proposal is accepted.

If a vote in the meeting achieves a 51% majority against a proposal (accounting for any explicit 0 votes), that proposal is rejected.

If a proposal in a meeting fails to achieve a majority either for or against, the FESCo members present must either:

• Present a new proposal, restarting the meeting voting process.
• Return the proposal to the ticket, restarting the ticket voting process above. All votes made in the meeting will be transferred to the ticket (Note: negative votes recorded in this way do trigger discussion at the next meeting as normal). Once FESCo agrees to return the proposal to the ticket, all discussion in the current meeting on the topic is ended until that ticket vote has concluded with either a decision or is transferred to another meeting.

Eligible voters on FESCo meetings are all currently-serving members of FESCo who have not explicitly voted 0 on a proposal.

Is this supposed to mean that FESCo members who are present during the meeting aren't allowed to change their mind from the in-ticket 0 vote? That's probably not the intention of this sentence.

Can we please just apply the Common Sense Rule here? I don't think it's that ambiguous that a vote can be changed.

If this were just about common sense, then we probably could've stopped after draft No. 2 :) But fine, I'm still +1 ...

+1

Sixth Draft

I've highlighted the changed portions from the previous draft for ease of review.

Ticket Votes (Preferred)

Once a formal proposal is made in a ticket, voting will proceed. A Change ticket is assumed to be a a formal proposal upon creation.

Eligible voters on FESCo tickets are all currently-serving members of FESCo.

An official vote in a ticket must be one of +1, 0, -1:

• +1 — I am in favor of the proposal as currently written.
• 0 — I am removing myself from the list of voters required for majority for this proposal. This has no effect unless the ticket votes are used for a meeting vote.
• -1 — I am opposed to the proposal as currently written. This topic must be discussed live in a meeting.

At the end of one week, if a proposal has at least 3 votes of +1 and no votes of -1 in the ticket, it is approved and may proceed with implementation. If there is at least one -1 vote, the ticket must be added to the upcoming meeting agenda and is subject to the Meeting Votes rules.

Any FESCo member may request a proposal be considered "Fast Track", and it automatically gets approved immediately if it receives +7 without any -1 votes. Any -1 vote removes the Fast Track request.

If there are insufficient +1 votes at the end of one week, one additional week will be granted. At the end of this period, if there is at least one +1 vote and no votes of -1, the proposal is approved. If there is at least one -1 vote, the ticket must be added to the upcoming meeting agenda and is subject to the Meeting Votes rules. If there are no votes at all, the proposal is considered rejected and the status quo will be maintained. The submitter may at this time make a new proposal which will be processed following the usual rules.

Meeting votes

At the meeting, a reasonable amount of time must be given for discussion. Once a proposal is made in the meeting, the vote will be tallied as follows:

Votes must be one of +1, 0, or -1, as described in Ticket votes.

In a meeting vote, a vote of 0 reduces the denominator of the fraction required to achieve the 51% majority. In effect, it says "I am agreeing to vote with the remaining majority, whatever they decide."

Any FESCo member is assumed to retain the last vote that they made in the ticket prior to the meeting. Note that this does not carry over to new proposals, with the exception of clarification edits.

If a vote in the meeting achieves a 51% majority of eligible voters, regardless of their attendance at the meeting and accounting for any explicit 0 votes, in favor of a proposal, that proposal is accepted.

If a vote in the meeting achieves a 51% majority of eligible voters, regardless of their attendance at the meeting and accounting for any explicit 0 votes, against a proposal, that proposal is rejected.

If a proposal in a meeting fails to achieve a majority either for or against, the FESCo members present must either:

• Present a new proposal, restarting the meeting voting process.
• Return the proposal to the ticket, restarting the ticket voting process above. All votes made in the meeting will be transferred to the ticket. (Note: negative votes recorded in this way do trigger discussion at the next meeting as normal). Once FESCo agrees to return the proposal to the ticket, all discussion in the current meeting on the topic is ended until that ticket vote has concluded with either a decision or is transferred to another meeting.

Note: I removed the repetition of the voting listing in the second section, and made some minor punctuation changes. This generally implements the changes suggested by Ben in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MJ5OJZM3VT5WW4GGEY5TGGHHRCVQXZBJ/.

We have discussed this during today's FESCo meeting. @zbyszek has prepared a (hopefully final) draft based on more feedback. There will be an associated fesco-docs PR shortly. Please vote on the sixth draft in ticket.

Non-procedural comment: Do we assume that the current "fast track" process is unchanged by this draft?

Oops. I edited the draft above to include the description of Fast Track again.

FWIW, I specifically had "minor clarification edits" because anything beyond that might actually change the meaning as understood by the person voting. That said, I don't care strongly enough to vote against this phrasing.

+1 to Draft 6

Yeah, but what is "minor"? I think that it it is a "clarification", then it cannot really change the meaning. I changed it to the simpler form because I think that simpler is better in general, and the chances of somebody abusing this are very small.

Works for me. I'm still +1

+1 to Draft 6

+1 to Draft 6

+1 to Draft 6

+1 to Draft 6

Thanks to everyone who worked through these revisions. 👏

@dcantrell, @kevin, @tstellar: please vote.

+1 to draft 6 I suppose.

After a week: APPROVED (+7, 0, 0)

Announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OBMMZPBV363JBINPKVN3X642GCEQ3GMC/

https://pagure.io/fesco/fesco-docs/pull-request/76