On 2024.04.15 17:24, Junio C Hamano wrote: > Josh Steadmon <steadmon@xxxxxxxxxx> 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@xxxxxxxxxxxxxx/ 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. > > 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
