Improve reference to voting rules from the voting process page

[tisonkun]

In bylaws 4.1, it writes (https://www.apache.org/foundation/bylaws.html#4.1):

... members of the corporation shall be admitted as members of the corporation only by a majority vote of the existing members of the corporation ...

And our glossary writes (https://www.apache.org/foundation/glossary.html#MajorityApproval):

Majority Approval
Refers to a vote (sense 1) which has completed with at least three binding +1 votes and more +1 votes than -1 votes.

So I'd try to keep the expression in sync to eliminate confusion. Not sure if it's a simple fact check or we should bring a discussion to the list.

cc @jvz

[dave2wave]

I don't think that the 3 vote rule applies here. I somewhat doubt that when we have several hundred members voting that one member will be elected 3 votes to 1 vote. This is a different kind of vote from a project vote.

[tisonkun]

@dave2wave Thanks for your information!

@gstein @ShaneCurcuru do you have the knowledge how STeVe actually works in this case (or we manually count)?

If we apply a different kind of vote from the "Majority Vote" defined in our glossary, perhaps we can update the glossary (maybe add a note); otherwise people who want to check rules integrity (like me :P) would confuse.

[tisonkun]

According to https://www.apache.org/foundation/voting.html, it seems actually only the release vote requires at least 3 votes?

[ShaneCurcuru]

When it comes to Annual Member Meetings, we use the definitions in the bylaws, not on the voting policy.

Those two kinds of votes (Member Meetings, and any other votes of any kinds, really) are probably best left as separate documents. The policies we want to have in place defining how PMCs officially approve releases or do other project-based things are very different than corporate meeting votes. I suppose we could add an informational blurb to any release or other vote processes to note that they are not related to Member Meeting procedures - but I don't think many people would really care.

Does that make sense?

[tisonkun]

I suppose we could add an informational blurb to any release or other vote processes to note that they are not related to Member Meeting procedures

Thanks for your information. Then I'll add this note to the glossary.

but I don't think many people would really care.

Yes exactly 🤣

[tisonkun]

Updated. I check the voting process page also and now my understanding is that the "minimum quorum of three positive votes" only applied for release.

[tisonkun]

I'll merge this patch tomorrow since we just clarified the words, and nothing effectively changed.

Ping @ShaneCurcuru as a reminder if you'd leave a review :D

[sebbASF]

I'll merge this patch tomorrow since we just clarified the words, and nothing effectively changed.

AFAICT, the patch does more than just clarify the wording for the 'Majority Approval' Glossary item.
The way I read it, the description is fundamentally changed, as the minimum quorum of 3 votes is dropped.
This means it is no longer in agreement with the 'votes on package releases'

I don't understand the reasoning behind the Glossary change/

[sebbASF]

AFAICT, the patch does more than just clarify the wording for the 'Majority Approval' Glossary item.
The way I read it, the description is fundamentally changed, as the minimum quorum of 3 votes is dropped.
This means it is no longer in agreement with the 'votes on package releases'

I don't understand the reasoning behind the Glossary change/

[potiuk]

AFAICT, the patch does more than just clarify the wording for the 'Majority Approval' Glossary item. The way I read it, the description is fundamentally changed, as the minimum quorum of 3 votes is dropped. This means it is no longer in agreement with the 'votes on package releases'

I don't understand the reasoning behind the Glossary change/

As I see it, it clarifies "Majority" voting to be "logic matches the description". while it also clarifies that "release voting" is "Majority + extra requirement of 3 +1s" .

So :

• it does not change how release voting is done - same rules as before just named differently
• at the same it clairfies definition of majority voting to make "sense" (accrding to it's name)

I like this change as it makes things more logical. Also I do not think it changes the release voting where the 3 +1 were used.

Do you think @sebbASF - it changes the way how we vote on other things than releases? Because it does not seem to change the logic of release voting? But maybe it changes other places where "majority voting" was used?

[sebbASF]

As I see it, it clarifies "Majority" voting to be "logic matches the description".

I agree that the name Majority Approval does not encompass all of the current description, but that does not mean that it is wrong.
Note that Consensus Approval also contains a requirement for at least three +1 votes. Given that these two are closely related, if one has to change then surely they should both change?

it also clarifies that "release voting" is "Majority + extra requirement of 3 +1s" .

It is not clear to me that there is an extra requirement here.

[potiuk]

I agree that the name Majority Approval does not encompass all of the current description, but that does not mean that it is wrong.

Surely. Nobody says it's wrong. I think current definition is just better and that's quite a good reason for a change if you ask me.

Note that Consensus Approval also contains a requirement for at least three +1 votes. Given that these two are closely related, if one has to change then surely they should both change?

I think that's ok as it is. "Consensus" does not have (at least for me) so clear meaning as "Majority" - and IMHO consensus approval is well defined in the docs, i do not feel it needs any change.

It is not clear to me that there is an extra requirement here.

It's quite clear to me, but maybe you have some doubts? What's concerning in the current statement and how can it be corrected to be clearer for you? Maybe you can propose some better wording?

[tisonkun]

I don't understand the reasoning behind the Glossary change/

We use majority approval in the following places:

1. Votes on procedural issues
2. Votes on package releases
3. (Soft referred in) Votes on new members

As discussed in this thread, only case 2 (vote on releases) requires 3 +1 binding votes. So to improve the words that only vote on releases has extra requirements, I modify the glossary.

[tisonkun]

Note that Consensus Approval also contains a requirement for at least three +1 votes. Given that these two are closely related, if one has to change then surely they should both change?

Each term can has its own definition, so I don't think it's an issue.

However, I noticed that we actually don't use the word "Consensus Approval" anywhere outside the glossary, while it's effectively used in the Normal Conditions of "Votes on code modifications". We may try to use the term there in a follow-up patch.

[sebbASF]

The change that is being proposed to the Glossary Majority definition would mean that a single +1 vote - and no others - would constitute a valid majority vote. I don't believe that is the intention. Note also that the original definition contrasts it with a simple majority, which is unfortunately not defined.

The way I read them, the Glossary [gl] and Release Voting [rv] descriptions currently agree on what constitutes a valid vote.

AFAICT this PR attempts to weaken the definition of Majority Approval, which then means the Release Vote definition has to be strengthened.

I think those descriptions should stay as they are.

However, I have just seen that the description of votes on procedural issues [pi] is confusing, and should be clarified. It refers to 'majority rule', which is not the same as Majority Approval. It should probably refer to Simple Majority (which needs to be added to the Glossary).

[gl] https://www.apache.org/foundation/glossary#MajorityApproval
[rv] https://www.apache.org/foundation/voting#ReleaseVotes
[pi] https://www.apache.org/foundation/voting#apache-voting-process

[tisonkun]

Hi @sebbASF.

Thanks for your investigation! It looks OK to me to add a new term, "Simple Majority", and update the voting process according to these terms.

I'll then refactor this patch as an improvement to the voting process page, with the corresponding addition to the glossary.

[potiuk]

However, I have just seen that the description of votes on procedural issues [pi] is confusing, and should be clarified. It refers to 'majority rule', which is not the same as Majority Approval. It should probably refer to Simple Majority (which needs to be added to the Glossary).

Good and constructive proposal. Thanks @sebbASF

[tisonkun]

Updated to try to adopt @sebbASF's comment.

[sebbASF]

I think the proposed changes are much better, and I would not have further objections once the extra phrase mentioned above is removed.

However, I do not have authority to formally approve them.

[sebbASF]

The phrase:
'the common format of majority rule,'
seems unnecessary to me, and potentially confusing.
I think it should be dropped.

[tisonkun]

@sebbASF Updated.

However, I do not have authority to formally approve them.

IIUC, we're using lazy consensus on these wording improvements.

I'll leave a few days for others in this thread to comment, and wording can be continuously improved if one has good ideas later. This is different from changing the meaning or editing the bylaws, which, IMO, would require more time to discuss on the list and call the consensus.

[sebbASF]

IIUC, we're using lazy consensus on these wording improvements.

I'm not sure that is your call to make.
Note that the overall responsibility for the apache.org site lies with M&P, and certain parts with legal, infra, trademarks etc.

Also, even minor changes to wording can subtly (or even significantly) change the meaning.

[tisonkun]

Thanks for your information. Yeah I'll notify @bproffitt here then.

@sebbASF do you find other unnecessary phrase? Hopefully b2f7df7 resolves your comment.

[sebbASF]

Yes, b2f7df7 addresses my comment.

Resolved.

[tisonkun]

Merged.

Post-Commit Reviews are welcome.

[tisonkun]

Now I can see the .asf.yaml file has a block somehow implies the "CODEOWNER" (or stakeholders):

www-site/.asf.yaml

Lines 11 to 35 in 8867ab8

	notifications:
	commits: site-cvs@apache.org
	issues: site-cvs@apache.org
	pullrequests: site-cvs@apache.org
	jira_options: link label
	commits_by_path:
	"data/eccn/*": legal-discuss@apache.org
	"content/legal/*": legal-discuss@apache.org
	"content/licenses/*": legal-discuss@apache.org
	"content/free/*": legal-discuss@apache.org
	"content/foundation/license-faq.*": legal-discuss@apache.org
	"content/foundation/marks/*":
	- legal-discuss@apache.org
	- trademarks@apache.org
	"content/foundation/marks/events.*": events-commits@apache.org
	"content/foundation/policies/anti-harassment.*": events-commits@apache.org
	"content/foundation/press/*": markpub@apache.org
	"content/foundation/contributing.*": markpub@apache.org
	"content/foundation/thanks.*": markpub@apache.org
	"content/foundation/sponsorship.*": markpub@apache.org
	"content/foundation/buy_stuff.*": markpub@apache.org
	"content/press/*": markpub@apache.org
	"content/security/*": security@apache.org
	"content/foundation/board/*": board-cvs@apache.org
	"content/board/*": board-cvs@apache.org

But the files touched in this PR are not identified in this list.