All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Antonin Delpeuch <antonin@delpeuch.eu>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Documenting the governance of the git project?
Date: Mon, 21 Sep 2026 15:09:56 -0700	[thread overview]
Message-ID: <xmqq7bkel0i3.fsf@gitster.g> (raw)
In-Reply-To: <1aee1829-d7ad-47e2-b7d1-1a946bd59991@delpeuch.eu> (Antonin Delpeuch's message of "Mon, 21 Sep 2026 18:08:02 +0200")

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.

  reply	other threads:[~2026-09-21 22:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-21 16:08 Documenting the governance of the git project? Antonin Delpeuch
2026-09-21 22:09 ` Junio C Hamano [this message]
2026-09-24  7:56   ` Antonin Delpeuch
2026-10-06 11:09     ` Antonin Delpeuch
2026-10-06 11:47       ` Christian Couder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq7bkel0i3.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=antonin@delpeuch.eu \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.