Re: [PATCH] Documentation: propose community voting process

[Patrick Steinhardt <ps@pks.im>]

On Sun, Oct 25, 2026 at 09:17:31PM -0400, Jeff King wrote:
> On Sat, Oct 24, 2026 at 02:18:56PM +0300, Tuomas Ahola wrote:
> 
> > Junio C Hamano <gitster@pobox.com> wrote:
> > 
> > > [...]
> > > I previously mentioned "topic count", but commits are far easier to
> > > count.  So instead of requiring two topics in released versions,
> > > perhaps requiring five commits would be easier to implement and
> > > explain.
> > > 
> > 
> > Quoting the summit notes:
> > 
> > } * Emily: Have we used a voting process for something like this before?
> > } 
> > } * Patrick: We need proposals and a vote. Who would be allowed to vote?
> > } 
> > } * Peff: Active developers with a track record; perhaps a threshold such
> > }   as 50 merged patches.
> > } 
> > 
> > So it seems that Peff's proposed threshold was substantially higher
> > than what has been put forth in this thread.  Any comments on that?
> 
> I'm a bit behind on the list and haven't been following this discussion
> closely yet, but I'll just say: the number 50 was made up by me on the
> spot. So I wouldn't read too much into it.
> 
> But if somebody is picking a number, looking at "git shortlog -ns
> --no-merges | sort -rn" may be interesting, just to get a sense of how
> many people we are talking about:
> 
>   - there are 44 people with >= 200 commits
>   - there are 133 people with >= 50 commits
>   - there are 439 people with >= 10 commits
>   - there are 2388 people with >= 1 commit
> 
> At some point it gets kind of unwieldy.
> 
> I saw proposals elsewhere to cut it by time. I think "N commits in the
> last M years" is awkward, because there are people who have been around
> for a long time with steady but slow participation steady-but-slow
> participation. But if you just intersect "N commits over all time" and
> "has _any_ commits in the last M years", then you can get a table like:
> 
> total    | Active in the last N years
> commits  |  N=1    N=2    N=3    N=5
> ----------------------------------------------------
>     200  |   17     22     24     30
>      50  |   34     47     56     67
>      10  |   71    104    124    155
>       1  |  239    357    457    628
> 
> Those aren't necessarily perfect metrics, but if we consider them good
> enough and just want to tune the parameters, we could probably pick a
> spot in the table that has about the number of votes we'd want to deal
> with.

That sounds very reasonable to me. Though I have to say that we
shouldn't only consider "the number of votes we'd want to deal with",
but also the shape of the voting population that we want to see.

I think it's fair to say that everyone has a single vote to cast no
matter their seniority so that the vote doesn't get overly skewed
towards the opinion of long-term contributors, as those tend to be
employed to work on Git. But the other side of the coin is that the vote
would get overly skewed towards newcomers in case we set the total
commit bar too low. So picking the right spot in the table would
essentially be balancing out the interests of oldtimers versus
newcomers.

How exactly we want to balance that is a different question. I am of
course heavily biased as an oldtimer and would thus think that 10
commits is a rather low bar. So from that table I myself would probably
pick 50 with N=2 or N=3, but maybe a commit count of 25 or 30 would be
more reasonable as a middle ground.

In any case, there is no "correct" value anyway.

Patrick