Re: [BuildStream] Proposal for committer policy update

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

Hi,

On Fri, 2018-09-14 at 10:21 +0100, William Salmon via BuildStream-list wrote:
> On 14/09/18 05:45, Tristan Van Berkom via BuildStream-list wrote:
> > Hi All,
[...]
> > If this proposal is not strongly opposed and is generally accepted,
> > then the next steps will be to create a COMMITTERS file in the
> > repository, outline the committer policy in the contributor guidelines
> > in HACKING.rst as the subversion project did (perhaps rewording it but
> > essentially saying the same thing), and define some of areas specific
> > areas of the BuildStream codebase. Off the top of my head I can think
> > of:
> >
> >    - YAML (base YAML parsing layer)
> >    - CLI/Frontend
> >    - Logging framework
> >    - ...
>
> I'm not apposed to your proposal however a middle ground might be just 
> to create this information as advice that you probably should get one of 
> these people to review? Apart from git blaming the file you are working 
> on I don't know a good way to find a good reviewer for a patch. And even 
> that can be a bit hit and miss.
>
> I think a issue with the current state is that the only people who 
> *seem* to be reviewing without a lot of cajoling are new people and 
> Tristan. Your proposal would be one method to force middle people to 
> review but just making it easier for new people to reach out to the 
> middle tear to encouraging middle people to review might have a very 
> positive effect.
>
> Its a lot less intimidating to write, "Hi, i see you are one of the 
> recommend reviews for the area of my patch, would you be able to take a 
> look" than having to start from scratch, also having there name in this 
> list would highlight to the middle people that they should be stepping up.

By a reading of your reply, I think that what you are saying is that we
should have a way for contributors to easily find the people who are
appropriate to review a specific area of the codebase.

I think that having this information in the COMMITTERS file provides a
clear solution to this.

Further than this, I think it can work the other way around, consider:

* Once we have defined some categories of the codebase, we should have
  labels in GitLab to represent these.

  Some of our more useful GitLab labels already do this categorization
  for us, e.g. is a documentation issue, a frontend issue, a logging
  issue, a cache server issue, etc.

  I would recommend that we make sure we always have labels for each
  of the defined categories; probably we should just make this type
  of label all the same color.

* People submitting merge requests, should make sure they are labeled
  after the category (or categories) which they effect (it would be
  nice to automatically inherit the labels from the issues which merge
  requests address where possible, but I don't think gitlab does this).

* People who are committers for a given area of code, can always filter
  the merge requests page by the category (or categories) for which
  they are committers.

Does this make sense ?

Cheers,
    -Tristan