Re: [PATCH] RFC: add MAINTAINERS file

[Linus Arver <linusa@google.com>]

Junio C Hamano <gitster@pobox.com> writes:

> "Linus Arver via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> From: Linus Arver <linusa@google.com>
>>
>> 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.