From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 21 Sep 2026 22:09:56 GMT
Subject: Re: Documenting the governance of the git project?
Message-ID: <xmqq7bkel0i3.fsf@gitster.g>
In-Reply-To: <1aee1829-d7ad-47e2-b7d1-1a946bd59991@delpeuch.eu>

Antonin Delpeuch <antonin@delpeuch.eu> writes:

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

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