DomainKey-Signature: a=rsa-sha1; c=nofws; d=toastin.space; h=subject:to
	:references:cc:from:message-id:date:mime-version:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=ml; b=QsOvyQsV
	BwbS6z83up10VJLfIT+zW6qkDMC/HRj81qMEQk/5ndq7jjSZd44lAnujdS0l9T6t
	Tvm8tTuGZJnMIeGjr5XsCz5ToAvkSschY5FUFKGVHYWG1sWlnfLr/dBKXV2Hfeuc
	/ChAyCbUJAYwpXboD3+vXeJ6Q8uNatVTuVyWP4milZA2xvw53ms8IhHg69k8f8ux
	t5F7aid3VxnQ62TN453bPXDIn/uwUvQ6auie/tTTartfO/y7t8RkwhpKZVkOHI6C
	LkQE0O8xsmIJZ07g7Xq4MY7vsSxzTlijO/xHCoylAwOXj3s6WocT5bgnc+iZGseB
	Ny2Wb1TIwSfopg==
Subject: Re: [alpine-devel] Stripping down the governance model proposal
To: 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>
 <2d40a15c-5be4-94ce-46ac-cdec4347ff53@lohutok.net>
Cc: Allison Randal <allison@lohutok.net>, Kevin Daudt <kdaudt@alpinelinux.org>
From: Chloe Kudryavtsev <toast@toastin.space>
Message-ID: <7e9005e0-307f-9b25-49b0-55e8700b2d01@toastin.space>
Date: Fri, 19 Apr 2019 14:44:00 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:67.0) Gecko/20100101
 Thunderbird/67.0
Precedence: list
MIME-Version: 1.0
In-Reply-To: <2d40a15c-5be4-94ce-46ac-cdec4347ff53@lohutok.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit

On 4/19/2019 1:07 PM, Allison Randal wrote:
> 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.

The goal of time-constraints is to make sure "moving forward" is happening.
Progress on things stalling is one of the issues we're trying to solve, 
after all.
Solving stalling by stalling the process of solving the stalling is not 
particularly effective - which is what the deadline idea's about.

> 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.

Okay.
The current list is actually as-written by Drew Devault.
I do mostly agree with it, and am fine with it being rewritten a few 
times to figure out the diffs and discuss those.

> 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.

Yes.
This is in fact the primary motivator for Natanael.
I have additional ones (as per the list, which I agree with).
I do believe that this point has been stated explicitly on IRC several 
times, but it makes sense to point it out in email too.

> 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.

Hopefully it's sufficiently clear by now that I'm quite strongly against 
the viewpoint you're outlining here. :)

>> 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.

I'm working on Alpine's documentation and the de-facto governance state 
would be on docs.a.o (currently beta.docs.a.o).
I initially put it in the developers handbook (which is being blocked by 
this being resolved), but it may make sense to actually throw it 
elsewhere (for now, or even in perpetuity).

>> 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.

As a summary of current arguments (in context of the current proposal; I 
think I mentioned it previously, but you can see it over at [1]).

- Using "Core" is inherently confusing: we are separating it out into 
two separate entities.
Calling either one "Core" will inherently give existing developers false 
ideas as to what that entity is.
- "Base" is not particularly descriptive.
I took it directly out of Gentoo, and it makes sense in some angles (i.e 
the "Base" of the Team "tree"), but it's caused enough confusion that a 
better name may be warranted.

> 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.

I'm aware: by the time I sent this in I had already acquired what I 
believe to be a pdf-formatted copy thereof (of course, being wrong is a 
thing, but I'll have to look at that later anyway).

I do indeed have a tendency to "throw myself" into things, which is 
further compounded by how my brain functions.
It might take a bit before I actually throw myself into it, thus the 
comment.

> 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.

As mentioned, [1] exists, but I'm not sure that's an appropriate place 
for the list.
Would have to think about where to keep it.
I think Kevin is supposed to be leading the working group now, so I'll 
CC him for this purpose as well.

Regarding capturing the existing governance structure, it gets a bit 
complicated.
We have an interim policy ([2], [3]), but it isn't really followed in 
practice.
In practice, nothing is really defined very well, so consolidating it 
into text is... challenging.

[1]: https://beta.docs.alpinelinux.org/developer-handbook/0.1a/
[2]: https://lists.alpinelinux.org/alpine-devel/6024.html
[3]: https://lists.alpinelinux.org/alpine-devel/6025.html

Note on [1]: current UI requires JavaScript for navigation. Writing a UI 
that doesn't from scratch to appropriately match the rest of Alpine's 
web presence is on the TODO list.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---