X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail.toastin.space (mail.toastin.space [207.246.93.162]) by lists.alpinelinux.org (Postfix) with ESMTP id 07B52F8554B for ; Fri, 12 Apr 2019 18:01:01 +0000 (UTC) Received: from mail.toastin.space (localhost [127.0.0.1]) by mail.toastin.space (OpenSMTPD) with ESMTP id cb92b6ab; Fri, 12 Apr 2019 14:00:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=toastin.space; h=subject :to:references:cc:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=ml; bh=rhz7un4hjylvYH HjZv/newsFkwk=; b=CRtsx7SgOMfWUOW+IsLZeX3kcHlPwl43OllUWAfxV9F/02 K4SYoWCkE2wANFJe3kdioHxMlHyVsOVKNuhD/YD1heKzGIcG0B/InKliEmwOxEKp U62/TkCZ21tn+TTPww0gTh1kANbiGP0E3usECN6/XHkCAtRLAEmATPmZDk2zaRGB 8p1D+JSz8cSc+AJfJcEmGQyLpHsjJ+t19quTcVqp7KtCFwRg/SVw19j8Cggpj4A1 IDmpjyllKYVEP4Ps5EqGFQVWouLU7ev2jw0NW0EsfO2wR249htsB4bm7N/IMnvnn 39x/h6Mlco9ipgvn7A89eXkH+WEloDHk/aS6GvOw== 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=EUq/HlkG LajzluQtekrlnUC7Mg3VVr1nv8xcVf/tnl4lNCApZY5/sU3kpWrVKmjyzk37Zh2v xUrr8t2UJck+0myPTHuFMCPrf5g0rDv/jT/xrkguznkTVbTBwywrW5ttvJNlcG4E v4PBaLqNGzaW6xbPgQTg3cHk0CYGEce3maY/JyQmKSyC4FuIoiPE6XFp1H05Epbw W944siWtXFd2qFA3ZUkd5hFhYg0nqSe8r/jboW/nCRAyG/p6RAidCP39ImCyCCi2 fbe7EuUm+F3u/soO2Q7xSSUbl1yosa3yaYLeZz8+Hma+Ht0WA3U8d7tqNSiceqQ2 BVX3OaDekXpOAg== Received: from [192.168.0.135] (173-246-15-165.qc.cable.ebox.net [173.246.15.165]) by mail.toastin.space (OpenSMTPD) with ESMTPSA id c8afb51d (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 12 Apr 2019 14:00:58 -0400 (EDT) Subject: Re: [alpine-devel] [RFC] New Governance Model To: alpine-devel@lists.alpinelinux.org References: <2a54dd89-9204-644f-6273-e5505d490e05@toastin.space> <20190411232750.70bd6b04@ncopa-desktop.copa.dup.pw> Cc: Richard Mortier , Natanael Copa From: Chloe Kudryavtsev Message-ID: <785d10ca-9eed-990e-d958-e44585bc4a52@toastin.space> Date: Fri, 12 Apr 2019 14:00:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:67.0) Gecko/20100101 Thunderbird/67.0 X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 4/12/2019 12:32 PM, Richard Mortier wrote: > If I read Chloe's email right about pushing discussion back onto this > thread from the other, then regarding the forced rotation for Base, my > 2c: > > I think there are advantages and disadvantages to such a model, and > it's not completely clear to me which dominates. > But does it have to be determined up front anyway? That's a good point - perhaps we need only make sure Base (or the project as a whole) has the ability to deal with any such situations as/when they arise. Still, looking at the (relatively now) newfound problems with forced rotation, I think it should be off the table indefinitely, at least for the near-to-medium future. > In the interest of moving forward, and as a question to the more > established members of the community: is there an obvious set of 3 > initial Base(*) team members (ncopa would be one presumably; are there > others? or perhaps just ncopa at first as the sole member of the > "bootstrap Base team"?) who could form it initially, and then run a > process under the new governance model to refine how the Base team is > constituted in future? Not part of that group (similarly to you, though I've clearly not been lurking). I think we could initialize with ncopa as the obvious initial 3-year-term member, and ask him to handle elections for the 2 and 1 year "initial" term members. My concern, however, is that this would add *more* work to do upon his shoulders (even if it's just a short-term thing). That is why I was suggesting finding someone else to handle said process. > That would allow time for proper consideration of different options > while also not blocking other things (eg., trying to get packaging and > other load distributed off of ncopa's shoulders). It might also serve > as a useful test of the new model (re voting etc), to see whether it's > really fit for purpose and able to evolve as needs change. In the > worst case, nothing much changes: ncopa ends up resolving fundamental > disputes and basically operates as BDFL, though hopefully with > slightly more help in other matters. More likely (hopefully!) some > structure gets created with which the community (including ncopa :) is > content, and so everything improves in line with the principles. The primary focus is very much de-centralization; teams that can self-govern to a large extent. Having that obviously requires structure, and that part is where we seem to have gotten stuck, to some degree. "Base" was never really intended to do much (even if they can in theory, in order to be effective at their job), but I can definitely see why a lot of discussion has been sparked from it. > (*) for want of a better name for now. ++ I believe it can be changed later if we ever figure out a better title. > Also FWIW, and by way of background for my suggestion above: my > experience of governance models (largely in academic environments > admittedly) is that they're never actually correct, only ever good > enough for now; and they fundamentally involve people interacting, so > it's possible to spend a remarkably long time trying to work out > wording of rules that end up never being needed because the people > involved simply don't behave in ways that would trigger those rules. > IMO it's more important to ensure that the governance model remains > "live" -- that is, understood and trusted by those involved in > whatever is being governed -- than to try and pre-emptively define all > the rules very precisely. That does seem to be what's going on here. Could you go over the current state of the document, and estimate what parts are missing vs what is "extra"? In case the link's been lost, I have it added in [1]. > Thanks! No, thank *you*. More eyes on the problem is usually good, and your 2c has been quite valuable :) [1]: https://beta.docs.alpinelinux.org/developer-handbook/0.1a/ --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---