Re: [BuildStream] Proposal for committer policy update

[William Salmon <will salmon codethink co uk>]

On 14/09/18 05:45, Tristan Van Berkom via BuildStream-list wrote:
> Hi All,
>
> Back in July, we introduced a new commit privilege policy so that there
> would be more reviewers with the ability to land patches, and so that
> simple patches which are mostly obvious fixes could land easily.
>
> In my opinion, this was a bit too aggressive in the opposite direction
> of having only a few reviewers for all patches (which was also bad for
> a different set of reasons).
>
> I don't believe the current policy is being abused, but I do believe
> that we should be more protective and have a better onboarding process
> for new committers in order to ensure that people are reviewing for the
> types of things we expect, and that people are seeking reviews from the
> right people.
>
> Updating the committer policy is one half of this, and the flip side of
> this is that we need to update the contributing guide in HACKING.rst
> (which is included in the published documentation[1]) to outline our
> coding standards and guidelines more clearly, such that people can more
> easily figure out what they should be watching out for when writing and
> reviewing patches.
>
> In our recent thread[2], Sander suggested that we consider the
> subversion model for onboarding committers[3].
>
> I suggest that people read the linked subversion committer policy, they
> are very simple and comprehensive; and I would propose that we simply
> use that policy verbatim.
>
> 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.
> And figure out who should be granted blanket access to the entire
> codebase, and who should be given commit access to the given categories
> only.
>
> At that junction, there are a couple of avenues to take, and I would
> appreciate input from our readership on how we should proceed:
>
>    * Grant all current committers blanket access, and proceed with
>      the policy moving forward.
>
>    * Grant only a few of our team members blanket access, and require
>      that anyone who wants commit access, be it blanket access or access
>      for a specific area go through the formal policy.
>
> I personally would be happier with an outcome where perhaps 20% of the
> current committers end up with blanket access, and "most" of our
> current committers end up with partial commit access to at least one
> area, than an outcome where 100% of current committers receive blanket
> access.
>
> This will ensure that right away, people will seek out reviews from
> those developers who are trusted for a specific area of code - so I
> would prefer the latter approach.
>
> That said, if we follow the first avenue things would still improve
> naturally over time.
>
> Cheers,
>      -Tristan
>
>
> [0]: https://mail.gnome.org/archives/buildstream-list/2018-July/msg00017.html
> [1]: http://buildstream.gitlab.io/buildstream/HACKING.html
> [2]: https://mail.gnome.org/archives/buildstream-list/2018-September/msg00042.html
> [3]: http://subversion.apache.org/docs/community-guide/roles.html#committers
>
> _______________________________________________
> BuildStream-list mailing list
> BuildStream-list gnome org
> https://mail.gnome.org/mailman/listinfo/buildstream-list