DomainKey-Signature: a=rsa-sha1; c=nofws; d=toastin.space; h=subject:to
	:references:from:cc:message-id:date:mime-version:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=ml; b=o+WFeq/s
	gkdPJI1Ohy1D2jpMq35Fqi+t5gReyHlB9EPWIGaWKyX0Jgj7GyEiSaueSvLB0d/G
	x1e0HhPXKo0AMN2ksu10vzg/+NSVcSs842VJu0z37QCUsuGzei+Q6pUZmUyY7HCz
	knOQ9IuNCwV+3NnSTODJpWBUv52wWKO/0fOdfz864c9LtNT6+J5okpzqeVpONIRj
	JvSgX/wSTLhHyIPHpOr1S2WNgCp0two5uXqpWm5kzA/WhBKdMpC97tzXju331bXs
	r6yIGKSmkoTdz1ZwksD4tGi0VS7UMBgLehi7K8HxL5nqbxUtgU2Ed4Ft2NpZZ8Le
	nrqtRlNoyovfig==
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>
 <7e9005e0-307f-9b25-49b0-55e8700b2d01@toastin.space>
 <be4c0c3c-7e00-a230-8462-cc0aeafd0a56@lohutok.net>
From: Chloe Kudryavtsev <toast@toastin.space>
Cc: Allison Randal <allison@lohutok.net>
Message-ID: <d639ae97-b7d7-69d7-0da2-fc765af8af42@toastin.space>
Date: Fri, 19 Apr 2019 15:44:06 -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: <be4c0c3c-7e00-a230-8462-cc0aeafd0a56@lohutok.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit

On 4/19/2019 3:15 PM, Allison Randal wrote:
> On 4/19/19 2:44 PM, Chloe Kudryavtsev wrote:
>> Hopefully it's sufficiently clear by now that I'm quite strongly against
>> the viewpoint you're outlining here. :)
> 
> Yup, understood. To be clear, I'm not advocating for any one alternative
> way of going about this, my goal here is just to help facilitate the
> community finding a path to change that works. The path that you
> personally prefer may not be the best one for the community overall. I
> think we can at least agree that the response you've gotten so far isn't
> what you hoped for.

I had hoped that I (with the help of comments from well-established 
members, as well as the community at large) would be good enough to 
figure out a solution that pleases most, and does not significantly 
impede the rest.
This obviously had not happened.
In terms of the response, my hopes were for one that results in 
improvement for the project.
Whether or not the response lives up to my hopes is yet to be seen.

>> 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.
> 
> Core at least has the advantage of already having an established meaning
> in the community, so people can talk about changing that meaning in a
> coherent and rational way. Starting over with something completely
> different is much more difficult.
> 
> I don't personally have any attachment to the word Core, so I'm really
> only advocating for holding the focus on changes that make the project
> and community more effective. The name change may be more distracting
> than helpful.

At this point I think the onus should be on me.
Since I can't think of anything better than "Base", perhaps "Core" 
should indeed be the way to go.
Still, this should be relegated to the roadmap (though I'd imagine it 
will end up being the first point) and discussed anyway.
However, unless someone has a better idea, I'm willing to go with 
"Core". (though again, I would very much like a better idea)

>> 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.
> 
> Nod, I reviewed the developer handbook (0.1a), but it does seem pretty
> tightly integrated with accepting the current proposal in its entirety.
> So, agreed that it seems sensible to keep the handbook separate from the
> list of things to consider working on.

Yes, I've effectively been using it to document the state of the proposal.
I think we can continue using it as such (for future parts/components of 
anything we end up with).
This way once we are fully done, the final state will be in sync.

>> 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.
> 
> Right, I wouldn't invest effort in cleaning up that interim policy, I'd
> just commit those email messages exactly as they are as a file in the
> repository (or page on a wiki, etc). That way, it is very clear to
> everyone what we have now (not much), and what exactly is changing.

That sounds reasonable.
That document can also be used for keeping/refining the list of issues, 
as well as the roadmap.

I initialized a wiki page[1] to serve this purpose.
Whether we end up using it or not for the other points remains to be seen.

[1]: https://wiki.alpinelinux.org/wiki/Governance


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---