{"thread":{"id":"66361","subject":"Documenting the governance of the git project?","startedAt":"2026-09-21T16:08:11Z","lastAt":"2026-10-06T11:47:46Z","messageCount":5,"participants":["Antonin Delpeuch","Junio C Hamano","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"552936","messageId":"1aee1829-d7ad-47e2-b7d1-1a946bd59991@delpeuch.eu","threadId":"66361","inReplyTo":null,"subject":"Documenting the governance of the git project?","fromName":"Antonin Delpeuch","fromEmail":"antonin@delpeuch.eu","sentAt":"2026-09-21T16:08:02Z","receivedAt":"2026-09-21T16:08:11Z","isPatch":false,"body":"Hi all,\n\nAs an occasional contributor to Git, I have been interested in getting a \nclear picture of the project's governance. By governance, I primarily \nmean a list of roles people can have in the project, the associated \nprivileges and expectations, the ways people get in and out of those \nroles, and any decision processes in place for important matters (which \n`Documentation/DecisionMaking.adoc` already does a pretty good job at \ndescribing).\n\nFor instance, I'm aware that Junio is the one merging patches, but are \nany other responsibilities delegated to other contributors? What are the \nresponsibilities of the Project Leadership Committee and how are its \nmembers renewed? If Junio wasn't available anymore, would there be an \nagreed on process to find a successor? Are those aspects of the project \ndocumented anywhere?\n\nThrough my experience in other projects, I have learned that it can be \nbeneficial to write such things down. I think it can help avoid some \nconflicts, help onboard contributors, spread responsibilities in a more \nintentional way and increase the bus factor. See [1] for more background \non the why and how of documenting governance. There is an emerging \nconvention to document those things in a `GOVERNANCE.md` file at the \nroot of the repository, but many projects choose to publish this \ninformation in other ways (such as on their website).\n\nIf there is interest, I would be happy to try and document this. All I \nneed is the confirmation that people see value in maintaining such a \npiece of documentation, and the readiness of project leadership to \nanswer my questions (which I would try to do in a way that respects \ntheir time, using the communication channel they prefer). I would then \nsubmit my write-up as a patch in the location/format you prefer. I would \nof course be delighted to team up with others in this endeavor.\n\nBest,\n\nAntonin\n\n[1]: \nhttps://theopensourceway.github.io/production/en/growing-contributors/project-and-community-governance.html\n\n"},{"id":"552955","messageId":"xmqq7bkel0i3.fsf@gitster.g","threadId":"66361","inReplyTo":"1aee1829-d7ad-47e2-b7d1-1a946bd59991@delpeuch.eu","subject":"Re: Documenting the governance of the git project?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-21T22:09:56Z","receivedAt":"2026-09-21T22:10:00Z","isPatch":false,"body":"Antonin Delpeuch <antonin@delpeuch.eu> writes:\n\n> As an occasional contributor to Git, I have been interested in getting a \n> clear picture of the project's governance. By governance, I primarily \n> mean a list of roles people can have in the project, the associated \n> privileges and expectations, the ways people get in and out of those \n> roles, and any decision processes in place for important matters (which \n> `Documentation/DecisionMaking.adoc` already does a pretty good job at \n> describing).\n\nI would refrain from commenting on how good a job that document\ndoes, but the way it describes how our community works does\nreflect the nature of our community, which is a loosely knit\ngroup of self-nominated volunteers.  'CODE_OF_CONDUCT.md' at the\ntop level refers to the Git PLC at SFC as \"Community leaders\",\nand that is the closest thing to an official structure we have,\nI think.\n\nSpecifically, we do not have an official list of reviewers with an\napproval bit or those with privileges and responsibilities to speak\nof.  Clout in the community, on both technical and non-technical\nmatters, is earned through continued contribution over time, and one\ninteresting side effect of this is that a totally new person cannot\neven know whose words carry weight before they are accustomed to the\ncommunity.\n\n> If there is interest, I would be happy to try and document this. All I \n> need is the confirmation that people see value in maintaining such a \n> piece of documentation, and the readiness of project leadership to \n> answer my questions (which I would try to do in a way that respects \n> their time, using the communication channel they prefer). I would then \n> submit my write-up as a patch in the location/format you prefer. I would \n> of course be delighted to team up with others in this endeavor.\n\nI am somewhat indifferent.  I wouldn't oppose it at all. I would\nwelcome a descriptive \"this is roughly how it currently works\"\ndocument, but it might be hard to come up with a good descriptive\ndocument.\n\nOnce the document starts trying to be prescriptive, it may open a\nbig discussion with different \"opinions\" not backed by any common\nexperience from which discussion participants can draw, which would\nlead to a lot of wasted time and effort.  That is the only thing I\nwould be a bit worried about.\n\nThanks.\n"},{"id":"553148","messageId":"33b3ab6d-b2cc-49c3-9a06-3c4070ede57e@delpeuch.eu","threadId":"66361","inReplyTo":"xmqq7bkel0i3.fsf@gitster.g","subject":"Re: Documenting the governance of the git project?","fromName":"Antonin Delpeuch","fromEmail":"antonin@delpeuch.eu","sentAt":"2026-09-24T07:56:01Z","receivedAt":"2026-09-24T07:56:10Z","isPatch":false,"body":"Hi Junio,\n\nThanks for your reply.\n\nOn 22/09/2026 00:09, Junio C Hamano wrote:\n> Specifically, we do not have an official list of reviewers with an\n> approval bit or those with privileges and responsibilities to speak\n> of.  Clout in the community, on both technical and non-technical\n> matters, is earned through continued contribution over time, and one\n> interesting side effect of this is that a totally new person cannot\n> even know whose words carry weight before they are accustomed to the\n> community.\n\nYes, I wouldn't try to codify the clout of project members in such a \ndocument. But even without that, I don't think we'd run out of things to \ndescribe. Just by reading the discussion from the Contributor Summit, I \nidentified a few more roles I hadn't thought about: the set of people \nwith access to the git-security list and the maintainer(s) of \ngit-scm.com. I imagine there might be other well delimited hats like \nthose, whose expectations and renewal process we could describe.\n\n>> If there is interest, I would be happy to try and document this. All I\n>> need is the confirmation that people see value in maintaining such a\n>> piece of documentation, and the readiness of project leadership to\n>> answer my questions (which I would try to do in a way that respects\n>> their time, using the communication channel they prefer). I would then\n>> submit my write-up as a patch in the location/format you prefer. I would\n>> of course be delighted to team up with others in this endeavor.\n> I am somewhat indifferent.  I wouldn't oppose it at all. I would\n> welcome a descriptive \"this is roughly how it currently works\"\n> document, but it might be hard to come up with a good descriptive\n> document.\n>\n> Once the document starts trying to be prescriptive, it may open a\n> big discussion with different \"opinions\" not backed by any common\n> experience from which discussion participants can draw, which would\n> lead to a lot of wasted time and effort.  That is the only thing I\n> would be a bit worried about.\n\nI think aiming for a descriptive document makes perfect sense (even \nhaving it state explicitly that it isn't prescriptive). Even without \ntrying to give it any authority, the questions asked in the process of \nwriting the document can be valuable on their own. They can prompt the \nteam to identify some gaps or some things that they want to change. That \nchange can happen at its own pace, independently of the documentation \neffort.\n\nFor instance, if the team behind git-security is struggling with a high \nvolume of reports, I wouldn't be surprised if by taking the time to \ndescribe who's on the team and how to get in and out of it, we might \nidentify people who'd be fit and willing to serve (for clarity, I am \ndefinitely not throwing my hat here - the task sounds absolutely \ndaunting). This is a random example: I'm not (yet) familiar with your \nexisting processes in this area, so it can be that I'm off-base on this \none, but I'm sure you get the broad idea.\n\nBest,\n\nAntonin\n\n"},{"id":"554267","messageId":"97c58bb0-5030-4e66-b183-44db2ab216db@delpeuch.eu","threadId":"66361","inReplyTo":"33b3ab6d-b2cc-49c3-9a06-3c4070ede57e@delpeuch.eu","subject":"Re: Documenting the governance of the git project?","fromName":"Antonin Delpeuch","fromEmail":"antonin@delpeuch.eu","sentAt":"2026-10-06T11:09:39Z","receivedAt":"2026-10-06T11:09:39Z","isPatch":false,"body":"Hi all,\n\nI am planning to go ahead with this project, unless anyone thinks it's a bad idea.\n\nMy plan is to write an initial document based on the information I can find on my own, and then fill the gaps by asking questions about the points I couldn't figure out myself.\n\nIt would be great if I don't have to bother Junio too much with those questions, so if you have a good grasp of the social structures in place in this project, I'd appreciate it a lot if you could let me know you're available to help.\n\nMy goal will be to write something that you are happy to include in the official documentation or website, but if that doesn't work out, I'll publish it externally (making its unofficial status clear, of course).\n\nThanks,\n\nAntonin\n\n"},{"id":"554269","messageId":"CAP8UFD1yx_Z+TyxYP6GA3xKOq12Y5OWfEbiHOEhx9bVZwZ0egw@mail.gmail.com","threadId":"66361","inReplyTo":"97c58bb0-5030-4e66-b183-44db2ab216db@delpeuch.eu","subject":"Re: Documenting the governance of the git project?","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2026-10-06T11:47:46Z","receivedAt":"2026-10-06T11:47:46Z","isPatch":false,"body":"Hi Antonin,\n\nOn Tue, Oct 6, 2026 at 1:13 PM Antonin Delpeuch <antonin@delpeuch.eu> wrote:\n>\n> Hi all,\n>\n> I am planning to go ahead with this project, unless anyone thinks it's a\n> bad idea.\n>\n> My plan is to write an initial document based on the information I can\n> find on my own, and then fill the gaps by asking questions about the\n> points I couldn't figure out myself.\n>\n> It would be great if I don't have to bother Junio too much with those\n> questions, so if you have a good grasp of the social structures in place\n> in this project, I'd appreciate it a lot if you could let me know you're\n> available to help.\n\nIf you write an initial document and send it to the list as a patch to\nadd that document to the Git code base, that would be a good start.\n\nThe people who will reply to your patch will be the people willing to\nhelp. That's how it works here. Someone could tell you they are\nwilling to help but then for example get sick or have a vacation when\nyour first draft is ready, and cannot actually help. That's why it's\nbetter if the process does not rely on people making such promises.\n\n> My goal will be to write something that you are happy to include in the\n> official documentation or website, but if that doesn't work out, I'll\n> publish it externally (making its unofficial status clear, of course).\n\nSure, no worries. I think we are not perfect, but overall do a good\njob at helping people who are willing to put some effort in useful\nquality work. In this case, if it's not accepted in the code base, nor\non the git-scm.org website, maybe we will accept it on the Git\nDeveloper Pages at https://git.github.io/ or as a \"How the Git project\nworks\" article in Git Rev News. Just trust the process and community\nas a whole that you are going to describe in your document ;-)\n\nBest,\nChristian.\n\n"}]}