Subject: Re: [alpine-devel] Stripping down the governance model proposal
To: Chloe Kudryavtsev <toast@toastin.space>,
 alpine-devel@lists.alpinelinux.org
References: <20190415152330.GG1179@homura.localdomain>
 <c5146728-ebc1-f90b-4333-6871c4402c6d@toastin.space>
 <0fdde07c-b505-fb2a-cff2-bba494c781e3@lohutok.net>
 <0712b237-864e-5304-f4e3-695d0a5207c6@toastin.space>
From: Allison Randal <allison@lohutok.net>
Message-ID: <a6e5bd2d-bfd1-f04d-359e-604439287105@lohutok.net>
Date: Fri, 19 Apr 2019 10:19:30 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.1
Precedence: list
MIME-Version: 1.0
In-Reply-To: <0712b237-864e-5304-f4e3-695d0a5207c6@toastin.space>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 4/18/19 9:15 PM, Chloe Kudryavtsev wrote:
>=20
> 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 tha=
t
> my hopes of this happening are not completely in vain - which is good.

That public discussion is absolutely essential, yes. You'll also find
that having more people involved in creating the proposal in the first
place, will mean that far more people are comfortable with what's
proposed. Part of that is the simple practical effect that capturing the
perspectives of more people in the proposal will mean that it more
accurately reflects what the community wants and needs. But, part of it
is also a network effect of trust, where it's easier for the whole
community to trust a proposal if several people with a long history of
respect in the project were involved in drafting it, and are confidently
saying that they're comfortable with it.

> 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.
>=20
> 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.
>=20
> The potential problem of that approach is that we lose holistic cohesio=
n.
> However, the extent of that damage is not too far-reaching, I would
> think - most FOSS projects evolve iteratively anyway.

The important thing to keep in mind is that the ultimate goal is to be
more effective as a project and community. From where we are today, we
can make some good guesses about what might be hindering effectiveness,
or what changes might improve things, but, we can't precisely predict
the effect any change will have, even a tiny one. That doesn't mean
projects should avoid change or be scared of it, but it does mean that
iterative changes are generally more successful, so that after each
change the whole community can look back, honestly assess what worked
and what didn't, and then decide what they want to change next.

Also keep in mind that there's no such thing as a perfect state, there
will always be things that can be improved. It's healthier to keep
evolving slowly and continuously, than to try to fix everything. You
never will fix *everything*, but you absolutely can get more and more
effective over time. Get into a habit of thinking that change is normal,
instead of putting it off until it's a big pile of messy things you want
to change all at once. (This is actually pretty similar to code changes,
it's generally better to make small patches iteratively, than to land a
massive ugly patch all at once.)

A roadmap can be helpful, but keep it as a living document, and modify
it over time as you learn from what worked. For example, you had a good
list of issues earlier in this email thread, which could serve as a
starting point of "things we want to work on in the next few years", and
everyone could add their own additional points to the list. Then,
everyone could talk about the list, and identify which things on the
list are the greatest obstacles right now. Then talk about one practical
change that would improve the greatest obstacle. Make the change, give
it time to settle in, then reflect on how it went. You might end up
refining the change a bit, to smooth out rough edges or address corner
cases that no one saw in advance. Once everyone is comfortable with the
one change and confident that it has made the project and community more
effective, go back to the roadmap list, and start talking about
practical changes to address the second greatest obstacle. This isn't a
rigid process, it's a dynamic living process, with flexibility to adapt
to the needs of the project. So, you might do two changes at a time, or
start one when another is only part-way finished, or revert a change if
it works poorly, or add new issues to the roadmap list, or remove issues
that become irrelevant because some other change worked better than
expected.


> [1]: Doran, G. T. (1981). There=E2=80=99s a S.M.A.R.T. Way to Write Man=
agement=E2=80=99s
> Goals and Objectives. Management Review, 70, 35-36.

If you're interested in that side of things (not everyone is), I highly
recommend:

Reynolds, M. & Holwell, S. (2010) Systems Approaches to Managing Change:
A Practical Guide. Springer.

I can also share some papers with you, writeups that I did applying the
concepts of traditional management theory to open source projects. The
ideas are not a perfect match, but there's a lot that open source
projects can learn from that field, as long as we take it as inspiration
and don't try to follow it too literally.

Allison


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---