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

[Taylor Blau <me@ttaylorr.com>]

On Mon, May 06, 2024 at 09:12:15AM +0200, Patrick Steinhardt wrote:
> On Fri, May 03, 2024 at 03:29:13PM -0400, Taylor Blau wrote:
> > On Fri, May 03, 2024 at 11:08:15AM -0700, Junio C Hamano wrote:
> > > > Yes, sorry for silence on this thread. I am working on a V2 but
> > > > probably won't have it ready today.
> > >
> > > Don't be sorry; the message was not addressed to you, but for wider
> > > community participants---especially the ones with more "clout" (or
> > > "long timers" or whatever word we would use to describe those whose
> > > opinions are trusted by others and count more) need to buy in if we
> > > were to first agree on that it is good to have a set of written
> > > rules, and to then agree on what rules to adopt.
>
> Fair enough. Given that I have been contributing quite a bit more
> recently I'll feel myself addressed here.
>
> > I have been meaning to respond to this thread since I was mentioned in
> > it by Emily, but have been unsure of what to say.
> >
> > On one hand, I think the document basically outlines the status-quo of
> > decision making for issues that are larger than the scope of a single
> > patch series (think "should we use Rust?", "what is our platform
> > support policy?", or "how should we approach libification?" not "is this
> > particular patch (series) correct?").
> >
> > So in that sense, I think that the document is a good starting point,
> > and I think that it reasonably captures the status quo.
> >
> > But I wish that we didn't have to have such a document in the first
> > place. In my opinion, I would much rather see decisions like "what is
> > our platform policy?" made according to discussions on a patch that
> > defines what that policy is. That way such decisions can be treated in
> > the same way as ordinary review is today, and we can avoid the need for
> > a separate process.
>
> With "such a document", do you refer to the one documenting the process
> to do such changes or the RFC-style document?

I did mean the former, but...

> If you mean the former I disagree and think that it would be great to
> document reasonable approaches for how to get to an agreement with the
> Git community. It's especially helpful for newcomers to the commuinity,
> and I do get questions around "How to reach consensus in Git" all the
> time at GitLab.

I think that this framing is more useful. I'd be happy to see us write a
helper document intended for new-comers that gives some techniques and
suggestions on how to drive discussions forward.

I would be less excited about a document that outlines a rigid process
for declaring when consensus has been met, since I think each situation
is unique, and the large-scale decisions that Josh's document seems to
target are probably not amenable to a one-size-fits-all approach.

> Now the important part to me is that we should retain flexibility and
> allow us to adapt. It should rather be a helpful resource to newcomers
> than a rigid set of requirements that everyone has to follow, in my
> opinion.

Yes, definitely.

Thanks,
Taylor