Mail archive
alpine-devel

Re: [alpine-devel] Stripping down the governance model proposal

From: Chloe Kudryavtsev <toast_at_toastin.space>
Date: Thu, 18 Apr 2019 21:15:51 -0400

On 4/18/2019 6:07 PM, Allison Randal wrote:
> There is a third possibility that's worse than those two: a proposal
> that fixes a large number of issues passes, but is generally not
> accepted by the community because they aren't comfortable with it. It
> becomes official, but no one respects or abides by it, and you
> effectively end up with no governance model at all, and a lot of
> confusion and disruption to the project.

That seems to be at least tangentially related to what happened to the
previous interim policy - it never ended up being followed.
My hope is that through discussing this in a public and transparent way
(rather than simply announcing "this is how it is now"), we can get
community members that aren't comfortable with parts of the proposal to
speak out, and for the debate to improve the proposal's state.
Considering the comments around the forced rotation stuff, it seems that
my hopes of this happening are not completely in vain - which is good.

> I can't say how likely that is to happen here, but it is definitely a
> common risk when considering such substantial changes. So, it's worth
> taking the time to carefully consider changes, make them incrementally,
> and ensure that the currently active governance body always leads
> changes to the governance model. Trust takes time.

I think having a concrete roadmap may be helpful.
Solve some issues at a time, but have a specific timeframe during which
we plan to solve the other issues, along with a "current state of the
discussion" for each planned iteration.

The concern with not solving all of the issues at once is that the
"we'll solve this later" may never come.
One way of solving that (and thus effectively allowing for iterative
approaches) is to follow SMART criteria[1], which would require a
roadmap (the T component: Time-constrained).
This would also allow us to merge the less controversial parts of any
proposal sooner, while giving much more discussion time and mindspace
(since the less controversial stuff has already been merged) for any
controversial components.

The potential problem of that approach is that we lose holistic cohesion.
However, the extent of that damage is not too far-reaching, I would
think - most FOSS projects evolve iteratively anyway.

[1]: Doran, G. T. (1981). There’s a S.M.A.R.T. Way to Write Management’s
Goals and Objectives. Management Review, 70, 35-36.


---
Unsubscribe:  alpine-devel+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Thu Apr 18 2019 - 21:15:51 UTC