On Sat, Mar 30, 2024 at 10:59:53AM -0700, Linus Arver wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Linus Arver <linusa@xxxxxxxxxx> writes: > > > >> I realize that such an idea is beyond the scope of a simple MAINTAINERS > >> (or similar) file that's checked into the Git code repo, but I think > >> it's worth stating as a thought experiment. > > > > As we already have agreed that neither of us care the exact format > > of the file (yet), regardless of how a contributor, who is about to > > send a patch, will find an area "maintainer" to help the patch along > > the process, it is far more important to discuss and decide what > > responsibilities and authorities are expected of these maintainers. > > I'm starting to think that the new responsibility should be as small as > possible, and build from there. So the smallest bit of (initial?) > responsibility expected of the new roster of maintainers could be > "maintainer must respond to CC pings on the list within 7 days". > > For those who have more time to spend on the project, the next rung of > responsibility could be "maintainer is available to review patches > outside of their domain of expertise if no one else has reviewed the > series in 7 days". > > I haven't thought too much about the "authority" part yet. One thing that makes me feel a bit uneasy about the authority part is that contributors to Git are quite often direct competitors on the company level, as well. This never has been a problem in the past, quite on the contrary: I really value the cross-competitor collaboration we have in this project. But I have to wonder what it can potentially lead to if we did assign more authority to some contributors. Theoretically speaking, that would allow for sabotaging interests of a direct competitor. Mind you, I don't think this would happen in the current state of the project. I'm merely trying to think about worst-case scenarios, which may or may not be helpful in this context. Patrick > > The development community has been fairly loosely organized so far, > > but I'd like to see responsibility and authority spread a bit more > > widely yet still not too thinly to compromise the project integrity. > > Agreed.
Attachment:
signature.asc
Description: PGP signature
