Documenting the governance of the git project?

3 messages between Sep 21, 2026 and Sep 24, 2026, from Antonin Delpeuch, Junio C Hamano.

Plain Markdown or JSON for tools and agents.

Antonin DelpeuchSep 21, 2026, 16:08 UTC on lore

Hi all,

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

For instance, I'm aware that Junio is the one merging patches, but are any other responsibilities delegated to other contributors? What are the responsibilities of the Project Leadership Committee and how are its members renewed? If Junio wasn't available anymore, would there be an agreed on process to find a successor? Are those aspects of the project documented anywhere?

Through my experience in other projects, I have learned that it can be beneficial to write such things down. I think it can help avoid some conflicts, help onboard contributors, spread responsibilities in a more intentional way and increase the bus factor. See [1] for more background on the why and how of documenting governance. There is an emerging convention to document those things in a `GOVERNANCE.md` file at the root of the repository, but many projects choose to publish this information in other ways (such as on their website).

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.

Best,

Antonin

[1]: https://theopensourceway.github.io/production/en/growing-contributors/project-and-community-governance.html

Junio C HamanoSep 21, 2026, 22:09 UTC in reply to Antonin Delpeuch on lore

Re: Documenting the governance of the git project?

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.

Antonin DelpeuchSep 24, 2026, 07:56 UTC in reply to Junio C Hamano on lore

Re: Documenting the governance of the git project?

Hi Junio,

Thanks for your reply.

On 22/09/2026 00:09, Junio C Hamano wrote:

Show 7 quoted lines

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

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

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