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