[BuildStream] Proposal: spreading responsibility and maintainership [Was: 1.4 Release timeline]

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

Hi Sander,

Forked reply for this one...


On Mon, 2018-12-10 at 13:13 +0100, Sander Striker wrote:
> Hi Tristan,
[...]
> > I am honestly not sure what the best answer to this is and hope we can
> > have an open and productive conversation and find a better approach.
>
> I think that for this cycle it's honestly mostly you and me butting
> heads over how a feature should work (specifically: build trees).

I've been wanting to make a statement about this for a number of weeks,
and I suppose this is as good a place as any.

We need to fix this so that this mailing list is not just a venue for
you and I to be butting heads, and I think that getting more
contributors involved in the hard conversations is our highest priority
right now.

I do have a plan for improving this situation, I want to set it in
motion, and only fear upsetting some people in the process, I am not
sure where to go from here but let's start by just putting it on the
table.

I'm coining this as a "proposal" to get people's attention, but I think
people are aware that this has been coming for a while, and I want to
put it all down in one place so that people understand the intentions
and hopefully have input on how we can do this well.


The Goal
~~~~~~~~
I want the project to be self sustaining and run by the individuals who
contribute to it, and I want that to happen without the project losing
a strong sense of leadership.

I.e. what we need is for more individuals who contribute to the
project, to step up and become leaders.

Ideally, I would like for our charter to be agreed upon in order to
ensure that our founding principals are respected and valued in the
long run, but if we cannot achieve that, or if the project's priorities
veer in directions that I don't like, then so be it.


How to get there from here
~~~~~~~~~~~~~~~~~~~~~~~~~~
I think there are a few essential factors which are standing in the way
of getting to a place with a more healthy community, where the barrier
of entry is as low as possible, and the road to becoming a maintainer
and decision maker is clear and fair enough.


Here is an outline of what I think we should do:

   Proceed with the committer policy change proposal
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   There was discussion on this before, and I formally proposed
   this back in September, and have been holding back.

     https://mail.gnome.org/archives/buildstream-list/2018-September/msg00044.html

   I like the subversion approach Sander suggested, and would perhaps
   only amend it to not require a private/archived mailing list for
   the communications of existing maintainers to vet new ones.

   This would be in the interest of progress, so as not to block on
   fussing about setting up such a mailing list and deciding where
   it would be hosted and all of that.

   This is an essential step towards spreading maintainership I think,
   as we need to have an official place where maintainership status is
   tracked.

   Coincidentally, gitlab.com has grown a "codeowners" feature that
   might be suitable for this:

     https://docs.gitlab.com/ee/user/project/code_owners.html

   Would it be a good idea to use this feature ? I personally feel that
   we don't need to strictly police the people we trust to commit to a
   given area of software, and that we can just trust them to only do
   what they have permission to do.


   Optimize the feedback loop, get contributors involved
  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   We need a way
to subscribe to the project level general
   notifications, and this
notification stream needs to be digestible
   and not overwhelming.

   For contributors to feel involved, they need to be included in
   the feedback loop, they need to be notified of bugs discovered
   in the field, and of merge requests which touch upon areas of
   their specific interest so that they can comment meaningfully
   without needing to be explicitly asked.

   I think that *at least* everyone who works full time on this
   project and initiative, should be subscribed to the general
   ongoings of the project - and that it really should only mean
   a stream of 5 or 10 emails a day maximum.

     o Movement on issues

       This includes:
       - Notification of new issues
       - Notification of closed issues
       - Notification of *meaningful progress* on issues

     o Movement on merge requests

       This should be only for merge requests which are really ready
       to be reviewed to merge.

   To achieve this, I think we should:

   - Only ever self-assign issues; an issue is only ever assigned to
     the person writing the code, not the reviewer, or the person you
     asked a question to.

     These generate notifications, and nobody else is interested in
     receiving notifications about an assignee ping pong game.

   - Only file merge requests when you are actually ready to request
     a merge.

     Remember that everyone is watching this notification channel,
     we dont want to spam everyone with every push you make to your
     work in progress branch.

   - Remove the status / priority labeling of issues

     This bleeds into my third point below, but also relevant here
     because assigning a label to an issue again generates
     notifications.

     It is enough for everyone to receive a notification about the
     initial labelling of how severe an issue is, or categorization
     as a documentation issue or a performance related issue; we don't
     additionally need to receive notifications about the status and
     priority of every issue.


   Dispel the corporate image, reduce visible micro management
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Currently I feel that the way we have structured things in the
   past year has led to a micro managed workflow.

   Because we purport to classify priorities and track the status
   of each and every issue, this has led us to a state of affairs where
   issues get escalated and then assigned back down a food chain of
   sorts.

   In this state of affairs, developers are not doing the dictating
   of what needs to be done, and I think this works against us if
   we want developers to have a sense of ownership and have the
   opportunity (or desire, even) to grow into maintainers.

   From a project perspective, we can at least improve the situation
   by putting the onus on the individuals contributing, and removing
   the public bookkeeping of status and priorities from gitlab.


Do other people have ideas of what we could do to improve the community
aspects of this project ?

Cheers,
    -Tristan