Junio C Hamano <gitster@xxxxxxxxx> writes: > "Linus Arver via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > >> From: Linus Arver <linusa@xxxxxxxxxx> >> >> This patch is designed to spur discussion about adding an official >> MAINTAINERS file to our project. The hope is that it could be used as a >> reference in (at least) the following scenarios: >> >> (1) [CC list] patch authors want to know who to CC on their >> submissions, without resorting to git-blame-level of precision; >> >> (2) [escalation path] patch authors have been waiting 1+ weeks for >> review comments, but are not sure who to escalate to (other than >> Junio); >> >> (3) [status tracking] record former maintainers/reviewers who are now >> inactive. >> >> In addition having a MAINTAINERS file could give a more official sense >> of ownership in the codebase. > > OK. They are understandable goals. > > As to the format of the actual file, I do not have much opinion. > What works for the kernel may or may not work for us, as the project > size is very different, but I am fairly confident that we can agree > on something usable. Agreed. > I am more worried about how the file is used and maintained. Some > things to think about while in the "spurred discussion" I can think > of are: > > - Is the project big enough to require this (especially for the > purpose of (1)), or would > > $ git shortlog -n --no-merges --since=24.months -- path-to-file > > be sufficient and more importantly the value that it will keep > current automatically outweigh the benefit of having this file > that can go stale? > > To answer this question, we'd need to know > the turnover rates of past project contributors, of course. If > it is too high, having such a list may help for (1) and (3) > above. In addition to checking git-shortlog on the Git repo, perhaps it's also worth running a similar query against the public-inbox repo of this list? We could perhaps use a script to generate this list automatically every Git release (or some other cadence that we undergo regularly)? > - How binding is it for a contributor to be on this list as an area > expert? Will there be concrete "expected response time"? It can > be different for each area expert, of course. I'd expect better > from those who work on Git as a major part of their job and > contributes some part of their work product back to the upstream, > than from folks who do Git as a hobby. Is each contributer > expected to volunteer to be on this list, with self declared > service level target? Ideally there should be some teeth to the document/agreement (esp for service level targets), but I think practically the best we can do is positive reinforcement. So maybe a prominent "The Git Code Review Team" web page (somewhere on git-scm.com?) with profile photos and short biographies should be enough to motivate people to stay engaged and keep their spot. 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. The overall point I want to make is that we need to be extra-thankful to those who sign up to say "yes, I can review patches in areas X, Y, Z" and recognize (in a very official way) their generosity in contributing back to this project. > - With many good reviewer candidates being employed in companies > and doing Git as part of their job, how would we handle folks > getting transferred out of the Git ecosystem? Unlike in a > corporate environment, nominating successors who have no track > record in the community by the current area expert would not work > at all. The successors themselves have to earn respect by > demonstrating their own competence, which would take time. Unfortunately I don't think there's a good answer here. I agree that only those who have demonstrated a good track record should become a "successor". OTOH, if we are fortunate enough to have multiple people sign up for a particular area, then maybe that can be a sub-team and finding a successor won't be such a big deal. It would only be a problem for those areas where there is only 1 person who signed up for it.
