Re: [PATCH] Documentation: propose community voting process

[Junio C Hamano <gitster@pobox.com>]

Emily Shaffer <emilyshaffer@google.com> writes:

Emily Shaffer <emilyshaffer@google.com> writes:

> +Voting in the Git Project
> +=========================
> +
> +For the most part, technical concerns in Git should be resolved by community
> +consensus - either on the mailing list or in one of the annual-ish Contributor
> +Summits. Voting should be used as a last resort when the community really and
> +truly cannot come to a compromise on a policy decision. As such, the initiation
> +of a vote should be generally agreed on by the mailto:git@sfconservancy.org[Git
> +PLC] or primary maintainer.

Nicely described.  I particularly like that this prevents us from
putting technical decisions to a vote, reserving voting strictly for
policy decisions.


> +Phase 2: Voting window
> +----------------------
> +
> +The final version of each seconded proposal will be collected into a ballot at
> +the end of Phase 1. When the ballot is prepared, eligible voters will be able
> +to vote by mail for two weeks, to make space for contributors' individual
> +timezone and availability differences. During this time the proposals may no
> +longer be altered; the ballot should refer to a specific version of the
> +proposal (e.g. `[PROPOSAL v4] Require emojis in commit subjects`) and any later
> +version of the proposal will be ignored.

Or any earlier ones for that matter.  Perhaps there should be a way
to uniquely identify the version.  By the time the proposal is so
solidified, it is likely to be in my tree, so we can use the commit
object name that adds such a proposal document (or the blob ID).

Then we can tell people that

    $ git fetch https://git.kernel.org/pub/scm/git/git.git/ seen
    $ git cat-file blob $BLOB_OBJECT_NAME

would give them the exact thing they are voting on.

I presume that this can be used for multiple-choice votes easily,
and can be adjusted for a proposal with multiple things to vote on
independently (i.e., "allow emojis in commit titles?" and "require
CamelCase in commit titles?" can be asked at the same time and
voters can give answers to each question separately).


> +Votes will be decided using <mechanism TBD>.
> +
> +Phase 3: Implementation
> +-----------------------
> +
> +When the voting window ends, the winning proposal should be merged to `main`
> +without delay by the maintainer. The commit message should be appended to
> +include a link to the top of the voting discussion thread so that the
> +discussion can be revisited by history divers in the future, as well as a brief
> +summary of the result of the vote (% in favor out of total number of
> +proposals).

Do you mean "number of votes"?  Or are we envisioning that there
will be N competing proposals and we vote to find out which one is
the most favored?

> +Voting Eligibility
> +------------------
> +
> +Votes are welcome from contributors who have authored a commit which has been
> +merged to next, or who have provided 2 or more code reviews, and who have not
> +been banned from participation in the project. All eligible contributor votes
> +are weighed equally, regardless of the overall number of contributions they
> +have landed.

That is a fairly low bar to cross, especially the code review count,
as it will not be easy to define and enforce some rule that rejects
a response to a patch that only says "thanks, I like the feature
this proposes" without reading any parts of the message.  

As it is hard to track patches that as in 'next' a few release
cycles ago without graduating in the end and the authors of such a
patch should have the same voting power as those whose patch is in
'next' in the current cycle, I would suggest strongly against using
'next' as a yardstick.

I would have expected to see something like "two or more topics that
appear in any released versions" instead.  Note that I said "topics"
here and not "commits", so your topic that consists of 17-patch
still counts as one.

> +To prevent dogpiling, contributions are only eligible for a given vote if they
> +landed before the beginning of the voting process (the kickoff email mentioned
> +above). That is, the code reviews must have been sent or the patch must have
> +been accepted before the initial email is sent. The intention is to ensure the
> +mailing list isn't spammed with low-quality reviews during the voting process
> +solely to increase the number of eligible voters on one side of the issue.

Hopefully the "in released versions" criteria makes the above a
non-issue.