Re: Documenting the governance of the git project?

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 21, 2026, 22:09 UTC
Message-ID: <xmqq7bkel0i3.fsf@gitster.g>
In-Reply-To: <1aee1829-d7ad-47e2-b7d1-1a946bd59991@delpeuch.eu>

Antonin Delpeuch <antonin@delpeuch.eu> writes:

Show 7 quoted lines

> As an occasional contributor to Git, I have been interested in getting a 
> clear picture of the project's governance. By governance, I primarily 
> mean a list of roles people can have in the project, the associated 
> privileges and expectations, the ways people get in and out of those 
> roles, and any decision processes in place for important matters (which 
> `Documentation/DecisionMaking.adoc` already does a pretty good job at 
> describing).

I would refrain from commenting on how good a job that document does, but the way it describes how our community works does reflect the nature of our community, which is a loosely knit group of self-nominated volunteers. 'CODE_OF_CONDUCT.md' at the top level refers to the Git PLC at SFC as "Community leaders", and that is the closest thing to an official structure we have, I think.

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.

Show 7 quoted lines

> 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.

Thanks.