Re: [PATCH] Documentation: propose community voting process

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Junio

On 23/10/2026 05:48, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
>> I agree we want to include those who contribute more widely, but I think
>> restricting the criteria to contributions on the mailing list where the
>> development of git takes place and the impact of any decision will be
>> felt the most is a reasonable place to draw the line. I'm not sure how
>> easy it is going to be to count reviews - does posting "LGTM" count or
>> do we want a more substantial contribution? Should verified bug reports
>> count? - that's also a useful contribution to the project.
> 
> We have patches focusing on documentation as well.  I do not think
> commit count necessarily gives undue advantage to code contributors.

Limiting it to commits does make it much easier to count. Thinking about 
the way the list works, I suspect anyone who would be included by 
counting reviews is probably going to have authored sufficient patches 
that counting reviews does not make much difference.

>> I also think it would be sensible to restrict eligibility to the current
>> set of active contributors, who will have to live with the consequences
>> of the decision, by requiring eligible contributions to have been made
>> in the previous two years. I have historic contributions in a couple of
>> projects that I'm not active in anymore and I would not expect to be
>> able to influence an decisions those projects make now.
> 
> But do you care about these past projects enough to (1) notice that
> they are having a policy discussion, (2) bother visiting them again
> to learn their current voting procedures, and (3) actually cast a
> vote to help improve them?  You may not have been active recently,
> but if you care enough, and if your past knowledge of how the
> project works still applies, wouldn't the project participants
> appreciate your input?

As I understand it the voting systems that are being proposed 
automatically send a voting link to those eligible to vote so I would be 
aware because I'd have received a voting link. Having a time limit also 
limits the amount of admin for the person running the vote, for example 
handling messages from someone claiming to be a past contributor whose 
email address has changed. The voting system is only going to be used 
when we cannot reach a consensus. Having seen how much time and energy 
people, with no real interest in contributing to git, put into posting 
to the list when we we first discussing changing the default branch 
name, I think we should be careful to limit the potential for bad actors 
to try and derail the vote.

> I would recommend reducing the number and complexity of conditions.
> Immediately after you say "last two years", I can hear someone else
> arguing "too short -- why not three?" or "too long -- why not one?".
> 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.

People could choose to bike-shed over any aspect of the eligibility so I 
don't think that is a reason not to consider a time limit. Justin has 
also raised the issue of restricting eligibility to current 
participants. I suggested 2 years as it includes regular contributors 
who are having a break for whatever reason while excluding those who 
have not contributed in the recent past, but I don't think the exact 
number matters too much. I don't have a strong opinion either way on 
patch series vs commit count so long as we don't set the bar too low. 
Whether we count commits, or merged patch series, it is quite easy to 
limit the date range that we consider.

Thanks

Phillip