From: "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>
To: "Phillip Wood" <phillip.wood@dunelm.org.uk>,
"Junio C Hamano" <gitster@pobox.com>
Cc: "Emily Shaffer" <nasamuffin@google.com>,
git@vger.kernel.org, "Justin Tobler" <jltobler@gmail.com>
Subject: Re: [PATCH] Documentation: propose community voting process
Date: Fri, 23 Oct 2026 16:18:14 +0200 [thread overview]
Message-ID: <037a97bb-af3e-4e20-9845-c2d92ed3a2c4@app.fastmail.com> (raw)
In-Reply-To: <f192e10b-c7d0-45d8-8f67-21383474d16e@gmail.com>
On Fri, Oct 23, 2026, at 15:49, Phillip Wood wrote:
> Hi Junio
>
> On 23/10/2026 05: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?
>
> 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.
And this is a very relevant example since everyone can have an opinion
on GenAI, just like main branch name bikeshedding. Contrast with some
technical topic that you would have to be involved in the project to
even care about.
Some people care whether software projects that they use but don’t
contribute to use GenAI.
>
>>[snip]
next prev parent reply other threads:[~2026-10-23 14:18 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 [this message]
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
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=037a97bb-af3e-4e20-9845-c2d92ed3a2c4@app.fastmail.com \
--to=kristofferhaugsbakk@fastmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jltobler@gmail.com \
--cc=nasamuffin@google.com \
--cc=phillip.wood@dunelm.org.uk \
/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