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. > > 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. > > - 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? > > - 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. > > There may be many others. Thanks for the initial comments! I will try to formulate a response soon while I consider your other comments also.
