From: Justin Tobler <jltobler@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Emily Shaffer <emilyshaffer@google.com>, git@vger.kernel.org
Subject: Re: [PATCH] Documentation: propose community voting process
Date: Thu, 22 Oct 2026 10:35:31 -0500 [thread overview]
Message-ID: <atokQ8nPx2StLq_O@denethor> (raw)
In-Reply-To: <xmqqfqxylnct.fsf@gitster.g>
On 26/10/21 03:06PM, Junio C Hamano wrote:
> Emily Shaffer <emilyshaffer@google.com> writes:
> > +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.
I also agree that the proposed eligibility requirements here seem quite
too low. From my point of view, ideally eligible voters would primarily
consist of individuals in the community that have both a vested and
current interest in the project. If an individual submitted a handful of
patches 15 years ago, but have not been involved in the community since,
should they still be eligible to vote? Maybe it would be worth
discussing whether contributions must have come from one of last X
releases in order to be considered eligible?
At the same time, if the requirements are too restrictive, the eligible
pool of voters may be significantly biased towards the most active
contributors which tend to work on Git for tech companies. That is not
to say this would inherrently effect how these individuals would vote,
but I worry it may not be entirely reflective of wider community
sentiment.
> 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.
I agree that counting topics in released versions seems better than an
commits in next.
-Justin
next prev parent reply other threads:[~2026-10-22 15:35 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 18:05 Notes from the Git Contributor's Summit, 2026 Taylor Blau
2026-10-06 18:06 ` [NOTES 01/07] Security mailing list and security process Taylor Blau
2026-10-06 18:06 ` [NOTES 02/07] Git 3.0 Taylor Blau
2026-10-06 18:06 ` [NOTES 03/07] Documentation Taylor Blau
2026-10-07 4:49 ` Todd Zullinger
2026-10-07 17:38 ` Junio C Hamano
2026-10-06 18:06 ` [NOTES 04/07] Outreachy sponsorship Taylor Blau
2026-10-06 18:06 ` [NOTES 05/07] What can we do next with pluggable ODB? Taylor Blau
2026-10-06 18:06 ` [NOTES 06/07] AI contribution policy Taylor Blau
2026-10-21 20:03 ` [PATCH] Documentation: propose community voting process Emily Shaffer
2026-10-21 20:05 ` Emily Shaffer
2026-10-22 10:01 ` Phillip Wood
2026-10-23 4:48 ` Junio C Hamano
2026-10-23 13:49 ` Phillip Wood
2026-10-23 14:18 ` Kristoffer Haugsbakk
2026-10-23 16:26 ` Junio C Hamano
2026-10-23 18:09 ` Kristoffer Haugsbakk
2026-10-23 22:08 ` Junio C Hamano
2026-10-23 14:31 ` Kristoffer Haugsbakk
2026-10-24 11:18 ` Tuomas Ahola
2026-10-24 13:03 ` Weijie Yuan
2026-10-24 14:56 ` Junio C Hamano
2026-10-24 15:06 ` Weijie Yuan
2026-10-26 1:17 ` Jeff King
2026-10-26 3:50 ` Junio C Hamano
2026-10-26 7:57 ` Patrick Steinhardt
2026-10-26 9:23 ` Tuomas Ahola
2026-10-26 10:41 ` Phillip Wood
2026-10-22 22:59 ` brian m. carlson
2026-10-21 21:22 ` Junio C Hamano
2026-10-21 22:06 ` Junio C Hamano
2026-10-22 15:35 ` Justin Tobler [this message]
2026-10-23 4:56 ` Junio C Hamano
2026-10-22 7:29 ` Kristoffer Haugsbakk
2026-10-22 12:44 ` Patrick Steinhardt
2026-10-22 22:51 ` brian m. carlson
2026-10-22 23:17 ` Junio C Hamano
2026-10-23 4:51 ` Kristoffer Haugsbakk
2026-10-06 18:06 ` [NOTES 07/07] Protocol v2 for pushes Taylor Blau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atokQ8nPx2StLq_O@denethor \
--to=jltobler@gmail.com \
--cc=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox