Re: [PATCH] Documentation: propose community voting process

["Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>]

On Fri, Oct 23, 2026, at 06:48, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
>>[snip]
>> 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?
>

I see the concern wrt. dogpiling from non-active contributors,[1] but it
seems very impractical. A dogpile (this was the word used so I’ll just
stick to it) a la GitHub issues means that someone links to a GitHub
issue (which is open to all) and many, many outsiders comment on the
issue. For example. But imagine this happening via social media. All of
the people ready to dogpile would also need to have contributed in the
past. How could you get a flood of such a filtered set?

Imagine vote whipping former Git contributors who have scratched an
itch, fixed a bug, or fixed three typos, 5–20 years ago, to get them
all to vote for or against something. Okay, again no one made this
argument.[1] But this is to illustrate that the worst-case dogpiling
(or vote whipping) is not feasible.

† 1: This is not to say that anyone in particular had this concern. But
     I could imagine it.

>[snip]