Re: [BuildStream] Proposal for committer policy update

[William Salmon <will salmon codethink co uk>]

On 17/09/18 11:04, Tristan Van Berkom wrote:
> 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
Yep it dose.

Thanks

Will