Re: Documenting the governance of the git project?

[Antonin Delpeuch <antonin@delpeuch.eu>]

Hi Junio,

Thanks for your reply.

On 22/09/2026 00:09, Junio C Hamano wrote:
> Specifically, we do not have an official list of reviewers with an
> approval bit or those with privileges and responsibilities to speak
> of.  Clout in the community, on both technical and non-technical
> matters, is earned through continued contribution over time, and one
> interesting side effect of this is that a totally new person cannot
> even know whose words carry weight before they are accustomed to the
> community.

Yes, I wouldn't try to codify the clout of project members in such a 
document. But even without that, I don't think we'd run out of things to 
describe. Just by reading the discussion from the Contributor Summit, I 
identified a few more roles I hadn't thought about: the set of people 
with access to the git-security list and the maintainer(s) of 
git-scm.com. I imagine there might be other well delimited hats like 
those, whose expectations and renewal process we could describe.

>> If there is interest, I would be happy to try and document this. All I
>> need is the confirmation that people see value in maintaining such a
>> piece of documentation, and the readiness of project leadership to
>> answer my questions (which I would try to do in a way that respects
>> their time, using the communication channel they prefer). I would then
>> submit my write-up as a patch in the location/format you prefer. I would
>> of course be delighted to team up with others in this endeavor.
> I am somewhat indifferent.  I wouldn't oppose it at all. I would
> welcome a descriptive "this is roughly how it currently works"
> document, but it might be hard to come up with a good descriptive
> document.
>
> Once the document starts trying to be prescriptive, it may open a
> big discussion with different "opinions" not backed by any common
> experience from which discussion participants can draw, which would
> lead to a lot of wasted time and effort.  That is the only thing I
> would be a bit worried about.

I think aiming for a descriptive document makes perfect sense (even 
having it state explicitly that it isn't prescriptive). Even without 
trying to give it any authority, the questions asked in the process of 
writing the document can be valuable on their own. They can prompt the 
team to identify some gaps or some things that they want to change. That 
change can happen at its own pace, independently of the documentation 
effort.

For instance, if the team behind git-security is struggling with a high 
volume of reports, I wouldn't be surprised if by taking the time to 
describe who's on the team and how to get in and out of it, we might 
identify people who'd be fit and willing to serve (for clarity, I am 
definitely not throwing my hat here - the task sounds absolutely 
daunting). This is a random example: I'm not (yet) familiar with your 
existing processes in this area, so it can be that I'm off-base on this 
one, but I'm sure you get the broad idea.

Best,

Antonin