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>
 <a6e5bd2d-bfd1-f04d-359e-604439287105@lohutok.net>
 <8fd994e4-2c1e-4507-9776-245acac44eab@toastin.space>
From: Allison Randal <allison@lohutok.net>
Message-ID: <2d40a15c-5be4-94ce-46ac-cdec4347ff53@lohutok.net>
Date: Fri, 19 Apr 2019 13:07:46 -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: <8fd994e4-2c1e-4507-9776-245acac44eab@toastin.space>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit

On 4/19/19 11:33 AM, Chloe Kudryavtsev wrote:
> 
> This seems reasonable.
> The main ask I'd have is that each of those iterative steps actually
> does something to fix a given issue (as opposed to the root of this
> discussion).

Yes, from what I can tell, everyone agrees about not making pointless
changes just for the sake of change. Any change needs to be grounded as
a practical step to help the project be more effective.

> If I at any point implied that the roadmap would be fixed in stone, do
> forgive me - that was not my intent.
> The roadmap should always reflect the current understanding of the
> situation.
> The only component I would be skeptical of changing (at least often)
> would be the expected time-constraint of the next step.
> I'd probably be comfortable with the "measure-do" approach: the first
> "deadline" is a guess; if it needs to be changed, it's fine, but the
> expectation is that through figuring out that it needs to be changed you
> also figure out a more reasonable one that should then stick.

I was probably mostly reacting to the SMART reference, since it's an
approach that tends to be more rigid.

It's fine to add dates if people find them helpful, just remember that
the dates are unlikely to ever be accurate. In the end, when you do a
specific thing isn't as important as just continuing to move forward.

> Regarding the list, I didn't compose it by myself or anything.
> This is a list of issues that came out of a talk in IRC, during which
> several people (including myself) attempted to analyze what problems
> were hurting efficiency, to come up with a concrete list of issues to
> resolve.

Nod, I didn't mean you invented it all on your own, only that another
person summarizing the same conversations you have all had together,
might add some different points, or emphasize different points as higher
priorities.

> I'm okay with adding more points on to it, but unless those points are
> directly related to the general results that we wish to change, I'd like
> that to happen after the current list is resolved (as I think the
> current problem set is of a higher priority than, say, "the CoC is
> weird" (it is)).

One point I didn't see mentioned clearly, which I have experienced
repeatedly in other projects both as a project member and as the project
leader: you all are putting an enormous burden on one person (Natanael),
and you're going to burn him out if you don't find a way to share that
burden across multiple people, and allow him some way to take a year off
sometimes. The risk of burn out is kind of implicit behind all the
points, but it's helpful to say it explicitly, and really focus on what
that means for the project. It is really tempting to think that what you
have now works well enough that no change is needed at all, but putting
that much stress on one person guarantees you will change at some point,
whether you do it as carefully planned change over time, or it's forced
on you all at once when the founder gets sick, has their time taken up
by other things in life, or decides to retire from the project. In my
experience, it's far better to start making small changes to share the
load early on, so everything is settled and working by the time you
actually need to give the founder a vacation.

> I would prefer keeping the roadmap document more complete.
> I.e we should have a list of practical changes that we believe will, in
> combination, resolve all issues, while each change helps resolve at
> least one.
> This obviously would not be set in stone, and be updated every time a
> change's effects have become obvious.

What would seem like the most natural place for this community to keep a
document like this? In a git repo? On a wiki? It doesn't need to be a
massively detailed document, a list of bullet points would be sufficient.

> However, this means that we have an innate advantage of being able to
> keep the goal ahead of us, rather than start discussing semantics (e.g
> the "Core"/"Base"/Other discussion that keeps creeping back up).

I have the impression that there's more than semantics to this question
of whether the current core continues or is replaced by something
entirely different. It's worth taking the time to understand these kinds
of objections.

> Will take a look.
> For reference though, my background is more philosophical.
> Rather than "learning about X", I "learned to learn".
> As such, I tend to appreciate well-formulated meritorious ideas, rather
> than particularly lengthy papers that continually attempt to lower the
> abstraction level and raise referentiality.

That reference is an entire book, so may be a bit much. I have a
tendency to dive in to every new topic with great gusto, whether it's
community management, software, hardware, or more random things like
quantum mechanics and astrophysics. But, I totally know that my own
style of self-teaching isn't right for everyone.

> Considering your actual experience in the field, I'm relatively certain
> that your writeups would not have the potential issues I outlined above.
> As such, I would be glad to read them, if you wish to share. :)

Most of my writeups are very practical, looking back on why some thing
or another went badly wrong, and how it could have been improved. I'll
send you one about the death of another Linux distro community. It was
struggling through a completely different set of problems than Alpine,
but I think it's helpful to see how fragile these communities can be,
and why caution and inclusive collaboration is so important in any change.


> In summary, and correct me if I'm wrong, the way forward is such:
> 
> 1. Refine the list of issues we are attempting to solve, while keeping
> it focused on the issues the working group wishes to solve (this
> approach can be re-used later, but by the community as a whole).
> 2. Think of a set of practical changes that, in combination, solve all
> of them.
> 3. Group them into sets, such that each set solves one specific issue.
> (minimal set size = 1)
> 4. Decide on a priority list for the sets, from most important to least
> important.
> 5. Establish a roadmap, with estimated dates and the expected changes
> for each date.
> Give enough time between each change for discussion.
> Expect that changes and dates will change, but attempt to limit the
> changes to the dates in order to remain time-constrained.
> 6. Enter an iterative process where we discuss the next change, improve
> it if needed, and at the deadline, either push it back (with the new
> knowledge of exactly how long it'll take) or implement it.
> Then, during the next phase, observe the effects, and either push the
> whole stack back, inserting an entry to refine the change in question,
> or move on to the next point if the results of the change are satisfactory.
> Note: all of this (6) should effectively be done in parallel.

Something like that, yes. I suggest stepping back to just focus on #1
for now, and working on the list in some shared space where this
community already has a habit of collaborating. I've seen one community
do quite well keeping this kind of thing in a git repo named
"governance". You could start by capturing the existing governance
structure as files in that repo, instead of just historical posts on the
mailing list. A wiki or etherpad could work just as well as a git repo,
as long as it's public and everyone can contribute.

Allison


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---