Re: [RFC PATCH] doc: describe the project's decision-making process

From: Josh Steadmon <steadmon@google.com>
Date: Apr 22, 2024, 21:10 UTC
Message-ID: <ZibSUPezSU3ZV1HA@google.com>
In-Reply-To: <xmqq34rmi28h.fsf@gitster.g>

On 2024.04.15 17:24, Junio C Hamano wrote:

Show 21 quoted lines

> Josh Steadmon <steadmon@google.com> writes:
> 
> > The Git project currently operates according to informal, unstated norms
> > when it comes to making bigger-picture decisions (above and beyond
> > individual patches and patch series). Document these norms so that
> > newcomers to the project can learn what to expect.
> 
> It would be a good idea to write things down to help newcomers, but
> the thing is, that we do not do that kind of design discussion +
> design review + implementaiton waterfall here very often (a notable
> exception was the sha256 transition design).  I am afraid that
> "according to informal unstated norms" is an overstatement.  We do
> not have any "process" concrete, nothing more than concensus
> building among amicable parties.
> 
> Most of the time, technical decisions are made on individual series
> and by the time the consensus is reached on the series that it is
> good, the implementation should be finished, and there is no
> separate "implementation" step.  Newcomers would probably want to
> become familiar with that part of the decision process before
> joining the "big picture" discussion, I suspect.

Yes, as I noted in the doc (but need to emphasize), I'm not intending to describe day-to-day patch review here. I'm thinking more of larger-scale discussions such as "Introducing Rust into the Git project" [1] or the spinoff discussion "Defining a platform support policy" [2].

[1] https://lore.kernel.org/git/ZZ77NQkSuiRxRDwt@nand.local/ [2] https://lore.kernel.org/git/CAJoAoZnHGTFhfR6e6r=GMSfVbSNgLoHF-opaWYLbHppiuzi+Rg@mail.gmail.com/

While clearly nothing has been decided on those topics, it seems to me at least that they follow a pattern of "discussion now, consensus (hopefully) soon, implementation later".

Or do you think it's more accurate to say that we rarely/never make decisions without patches? Does that mean it's pointless to start a discussion without a patch series attached? I'm trying to decide whether it's worth editing this doc for V2, or just starting over with a much smaller one instead.

Show 27 quoted lines

> > One particular blind spot for me is how the Project Leadership Committee
> > operates, or if that's even relevant to this doc.
> 
> I think this is the part PLC@SFC is supposed to be of relevance:
> 
> > +For non-technical decisions such as community norms or processes, it is up to
> > +the community as a whole to implement and sustain agreed-upon changes.
> 
> > +Anyone with an interest in the topic is welcome to discuss the matter. It is
> > +expected that all discussion will adhere to the Code of Conduct rules.
> 
> It is very much worth mentioning CoC here.
> 
> > diff --git a/Documentation/Makefile b/Documentation/Makefile
> > index 3f2383a12c..a04da672c6 100644
> > --- a/Documentation/Makefile
> > +++ b/Documentation/Makefile
> > @@ -103,6 +103,7 @@ SP_ARTICLES += howto/coordinate-embargoed-releases
> >  API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
> >  SP_ARTICLES += $(API_DOCS)
> >  
> > +TECH_DOCS += DecisionMaking
> >  TECH_DOCS += ReviewingGuidelines
> >  TECH_DOCS += MyFirstContribution
> >  TECH_DOCS += MyFirstObjectWalk
> >
> > base-commit: 436d4e5b14df49870a897f64fe92c0ddc7017e4c