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

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

Hi Laurence,

On Tue, 2018-12-11 at 20:28 +0000, Laurence Urhegyi wrote:
> Hi Tristan,
[...]
> >    - 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.

I don't disagree at all with that, but gitlab doesn't have a feature
for it, it doesn't even have a feature to look at the merge requests UI
and exclude the WIP merge requests.

While people can discuss their branches outside of gitlab, we cannot
produce a clean feedback loop which excludes WIP stuff with the current
gitlab limitations, and I strongly believe that including developers in
the feedback loop is a necessary step towards empowering developers and
putting the developers in the driver seat.

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

So what you might not realize, is that the vast majority of software in
FOSS projects is funded and driven by full time developers.

The projects themselves tend to be hosted by impartial organizations
and legal umbrellas for FOSS projects, but asides from some enthusiasts
 and hobbyists, the development itself is done by paid developers,
these developers are effectively the voice of their employers.

These projects however come across as perfectly open venues where
anyone can contribute, everyone can have a say, regardless of whom
their employer is, or whether these developers are even allowed to
divulge who is paying for the work (it is quite a common occurrence for
a company to budget work, but hesitate about making their contribution
public knowledge).

So I understand that in the current situation it may feel like a
facade, but this facade is important to create the openness to make it
a safe place for others (individuals and companies) to contribute. If
or when we do get a more diverse contributor base, it will feel less
like a facade, and I think you will agree that appearances were an
important factor in getting us to that point.

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

While I agree that we need to tone it down a notch or two; people will
always have strong opinions when they take pride in their work and need
to argue with others and come to agreement, I think that is a natural
fact of life. On the flipside, we need more people who have strong
opinions and take pride in their work to step up and become
maintainers.

For my part in the "dramatic hyperbole", I'd like to say that life will
be much easier for me when more people step up and share the burden of
maintainership.

I don't like being the only one who has to say "no", any more than
anyone else likes it. It takes its toll and results in some outbursts
on my part, I apologize for that, and the very intent of this proposal
is to try to create an atmosphere where that doesn't happen.

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

It really is apples to oranges, and I would argue that if the only
criteria for a patch to land in freedesktop-SDK is that the pipeline
passes, then there is a problem there (although I cannot believe this
is really the case, for instance there must be a decision process
behind what is acceptable to add to the Flatpak runtimes).

For BuildStream, "working" software is definitely a minimum barrier,
but I think what we are all mostly concerned with is ensuring that the
software "makes sense" with every patch that lands.

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

The only way to measure the *coherency* of the software is with review.

Any measure of automated testing will only ever ensure that the
software behaves in the way it is tested to behave.

Frankly, it is much more important that the software makes sense than
whether it works properly; because as long as the software is coherent,
it can be easily fixed to work properly, the inverse is not that clear
cut.

I think that you are underestimating how easy it is to end up in a
situation where the software "works perfectly", and every minor change
becomes incredibly expensive (and eventually impossible) to make,
because nobody can understand the code anymore.

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

Definitely this, and I would say it is an understatement.

The individual who is going to implement a complex feature should be
the individual who made the proposal on the mailing list, and it should
be the same person representing the feature throughout the entire
process.

Now, when you say that a developer should provide a full breakdown of
the work to be undertaken, I think this goes beyond what individual
changes need to be done, and extends to how the developer will approach
the work, and what will be done in what order, and what will be tested
and known to work before proceeding to the next step.

I also think that this part of the break down is off topic, i.e. this
all depends on how you want to do your work, and is out of scope for
the public project.

  o From your perspective as a manager of developers who contribute to
    BuildStream, it might make sense for *you* to mandate that people
    do these breakdowns and have them peer reviewed.

    In this breakdown, I would recommend that the feature proposal
    itself be a part of the breakdown of things to do, and that
    proposal might not always even be the first thing to do.

    For instance, there are sometimes cases where you don't really know
    if something can work until you've done a rough prototype, or you
    might not know what UX makes sense until you've gone through the
    thought process of trying to implement it.

    When that prototyping is cheap enough to try, then it can make
    sense to prototype before proposing, and come up with a more
    complete proposal that takes less time to iterate over in public.

  o From the project perspective, we should expect that individual
    contributors are responsible professionals who will do this anyway
    by default, and we do not *require* a full step by step break down
    of what will be done in what order.

    It makes sense to discuss all of the changes which are proposed to
    the software, but not the step by step workflow process and
    planning of how a developer sets out to achieve their goal.
 
    At the same time, we should always welcome individuals asking
    for help in whatever they are trying to do on public channels.

Does this distinction make sense to you ?

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

I am more and more ambivalent about the approvers; especially if there
is only one required approver and that those who have sufficient
permissions can self approve.

My main worry with approvers comes from my experience with gerrit's
voting system, which I believe allows people to "pass the buck" when it
comes to reviews, at least in the settings where I've used gerrit.

Cheers,
    -Tristan