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

[William Salmon <will salmon codethink co uk>]

I wrote this last night before anyone else had replied however I was not 
able to send it until now

I think some of Angelos' comments are related to the topics I coved but 
don't materially change the thrust of my points

On 11/12/2018 11:06, Tristan Van Berkom via BuildStream-list wrote:

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


This seems to be implying that people are not getting in involved as 
developers
because it is hard to become a maintainer.

I think the path for people becoming developers is when people start 
using it
and then get interested in improving it.

If you want more "organic" developers then I think firstly making it easy to
learn and secondly use and thirdly submit submit patches should be the 
priority.
Not making it easier to be a maintainer.

That is not to say we should not make it as easy as possible to be a 
maintainer
but that we should not conflate the two.


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


Again I think this makes it easier for maintainer and slightly harder for
developers to keep track, this is not to say it is not valuable.


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


In my experience Gitlab does not have a good way to review a branch without
creating a merge request.

You can push a branch and get people to review individual commits but 
getting
the diff of all the commits to master or keeping track of the comments for a
branch is very hard, especially after a rebase. I have tried to do this 
to delay
the point at which i make MR and it is a terrible workflow.

There for if we want to make it as easy as possible for people to submit 
their
first patch then using a WIP MR and getting some nice gentle feed back 
in the
WIP state before them move to the non-WIP full review seems right for 
new people.

It is a work flow I would miss greatly but that i could live without.

I appreciate that this does create more mail but given how easy it is to 
create
a rule that just puts all the WIP MR emails in your emails trash I think 
it is
a useful trade off.


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


Given the reality that almost all of our developers have their 
priorities set
for them, then allowing others in the project to get a feel for why 
things are
happening the way they are seems fair to me. The little labels don't dictate
how a new independent developer would spend there time but would let 
them see
why others are acting the way they are so i fail to see the importance 
of this.


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


Making it easier to use and get started with?

I think the way to get more developers is to get more users.

Currently the doc's and Sam Thursfield's blog are the only public 
resources to
introduce and ease people in. And I am unaware of something that really 
sells
buildstream with a simple guide of how to take advantage of just a 
little bit of
the bst goodness.

Freedesktop and the Gnome meta project are great resources for a 
intermediate
level user but they require a fair bit of knowledge before they can act 
as examples.

However having lots of examples makes it more likely that the example 
will be
close to what a new person will want to do however we have a policy of 
not having
examples overlap which effectively minimizes the number of examples in the
official doc's. Which would be fine if we had lots of other example out 
there
in blog posts etc

As for improving the community feel for those already developing it then 
maybe
giving them the opportunity to work with it as well as on it might help 
matters?


>
> <snip>