Re: [PATCH] RFC: add MAINTAINERS file

> "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.
>
> 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.