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

[Laurence Urhegyi <laurence urhegyi codethink co uk>]

Hi Tristan,

Firstly I said that I would round up our discussion of the changes to 
the gitlab policy and update my MR, but I haven't gotten around to this 
so I apologise, I'll try to update it this week though, if we can get 
further comments on the below points from others.

On 2018-12-11 11:06, Tristan Van Berkom via BuildStream-list wrote:
<snip>
>    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.

+1

I like the subversion approach as well, I think it makes a lot more 
sense that the blanket access we provided for having just one successful 
patch post-GUADEC.

Do we even need a private ML for this? Surely the discussions can be 
done via emails addressed to individuals, that's what I had in mind when 
reading the policy anyway.

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

Looks like a neat feature to me. FWIW, I started to collate information 
on the wiki about who is familiar with which area of the codebase:

https://wiki.gnome.org/Projects/BuildStream/Codebase%20Expertise

I admit that I do need to push harder on getting this in good shape 
though. It could well end up being superseded by CODEOWNERS, which I 
would welcome.

>    Optimize the feedback loop, get contributors involved
<snip>
>    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.

+1

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

In principle I agree, as this will hugely decrease notifications, but I 
know how useful the comments/discussions on a WIP MR can be for 
developers. Will leave it up to others to comment though.

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

Not for me it doesn't, nor any of the people I've asked about it, which 
is very odd.

I feel like some categorisation of the tickets makes a lot of sense for 
such a large project, and it's been useful in the Monday morning 
meetings. Whether we should simplify it and just have Priority or 
Impact, I don't know.

>    Dispel the corporate image, reduce visible micro management
>    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<snip>
>    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.

My only comment here was going to be that you're talking about 
'corporate image' (which I think is an overstatement) - the reality of 
the situation is that the *vast majority* of contributors to the project 
are in fact all paid developers, and it feels like a bit of a facade to 
pretend otherwise. Certainly when I have been encouraged to use phrases 
such as 'let's find a volunteer for that' when in actual fact I am 
telling someone to do the work, it has felt like a silly dance. But 
that's maybe a different matter, and I really don't feel strongly, I 
defer to the more experienced folks involved in the project as to how we 
approach this :)

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

1) I find all the dramatic hyperbole rather boring, to be honest. And I 
think it's quite off putting - we could do less of that and be more 
friendly to contributors if we want some more of them. Not to mention 
that it loses all effect when over-used. We should be setting a positive 
example at all times.

2) I think we can take some lessons from the Freedesktop-SDK project, 
which does actually have a track record of attracting unpaid 
contributors, who do great work and really feel part of something. 
Different project and a different situation, I know, but one example is 
that they have a bot in place which allows automated merges of your MR 
as long as the pipeline passes. Thus, as a contributor, your patches are 
often accepted quickly, which, put simply, makes you feel quite good. 
Again, I realise it's a different situation and it'd be *a lot* of work 
to set up on BuildStream.

But I feel that empowering contributors and making them feel good is 
really important. I honestly feel like the code review process is a long 
and drawn out affair which can sap the energy and good-will from 
everyone involved. I realise that the benefit this brings is a very high 
bar of quality for the code that is committed to the project. But it's 
only one way to measure code quality, as Agustin has commented many 
times. And I feel that the lack of pace that it causes and the way it 
makes contributors feel means that, in my opinion, the negatives 
outweigh the positives. This is not a criticism but a comment that we 
need to change the culture around getting patches accepted. With the 
committer policy outlined above we can achieve improvements here.

For 'breaking changes' or seriously complex features, we need to 
encourage the contributors who will be developing the feature to be 
involved in the 'hard discussions' from the start of them (even if only 
a little, keeping abreast of them and providing a summary email that 
gets verified by the stakeholders, as happened with the workspace UX 
changes) or to provide a full breakdown of their understanding of the 
work to be undertaken before they start developing. This can then be 
referenced by reviewers at review time, instead of bottle-necking on the 
expertise of yourself and Juerg.

Also, in lieu of not having the auotmated testing in place to be able to 
have a merge-bot, I am I strong advocate of the 'approval' feature in 
gitlab. I've seen it work well on Freedesktop-SDK (prior to the bot) and 
then on the BuildGrid project, where we set the policy to be 'one 
approval is needed on your MR before merge, by someone from the 
specified list'. This empowers people and they take it seriously, in my 
experience.

3) Not really an idea but....the traffic on this mailing list has also 
been very high recently - for the first time ever I am struggling to 
keep up. Not sure if there's a lot we can do about that, though. And 
this long email is only adding to it.... :)

Thanks for reading, look forward to summarising this ramble later 
sometime soon :)

Cheers,
Laurence