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
