[BuildStream] Proposal for committer policy update

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

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

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