Thread (5 messages) 5 messages, 3 authors, 3d ago

Re: Documenting the governance of the git project?

flat view

From: Junio C Hamano <hidden>
Date: 2026-09-21 22:10:00

Antonin Delpeuch [off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help