X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by lists.alpinelinux.org (Postfix) with ESMTP id 4527CF84E86 for ; Fri, 12 Apr 2019 16:32:38 +0000 (UTC) Received: by mail-ed1-f66.google.com with SMTP id o26so8826346edv.12 for ; Fri, 12 Apr 2019 09:32:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hNwT7wEztLEfhSp4vZgPSJlsF85sSRZ/yiL9kavIMSg=; b=mCdlKjO3KzmD4o1wyL49dLgHwtpvekeS2ul5X7keLVi2vI/mntHC3hUXnCM3vapr1E yEt6t+qNcomGJZnBF96LW1vPoqeM2QeC5vyuj+SawDRByhhIqpyde++qApBtG0gwaN+t s9a0llFjjNLw6zzlUvaDIbgEjQyS/7vMOd7wsmHcwBUBMdAe0QkufFxpOtzd2qz06U5b syfrkiub2HdkKTaRfCJs93kjU0M5Dwnuq9Twu2TZba0OA1qyTOo0r0cwNHrs/Rq4rvg3 kLpA5CUvbL7RGZYLGrJcgwFA03USt0h8cLLCb86UJf/90/5prFhYhXtO7bmxal8SqTXG mkiw== X-Gm-Message-State: APjAAAVCmcRQjrzWWAm0rQXsNxZkXFUdAKWmWqcZi9PM5K0x98EFoSv8 lhi44n27IPlD+j6ppxQgtx73kHmTpifCFqPcJMk= X-Google-Smtp-Source: APXvYqzKVCcZXfeIR8CAh8bHq+QnUUgTShAQsSnvDUfczEzeB8qufXKCsy9AL0mldjuVT19Hi0BFsMWPrBuXP/Qt75I= X-Received: by 2002:a50:cb06:: with SMTP id g6mr18779511edi.89.1555086757640; Fri, 12 Apr 2019 09:32:37 -0700 (PDT) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 References: <2a54dd89-9204-644f-6273-e5505d490e05@toastin.space> <20190411232750.70bd6b04@ncopa-desktop.copa.dup.pw> In-Reply-To: From: Richard Mortier Date: Fri, 12 Apr 2019 17:32:25 +0100 Message-ID: Subject: Re: [alpine-devel] [RFC] New Governance Model To: Chloe Kudryavtsev , alpine-devel@lists.alpinelinux.org Cc: Natanael Copa Content-Type: text/plain; charset="UTF-8" On Fri, 12 Apr 2019 at 01:07, Chloe Kudryavtsev wrote: > > On 4/11/2019 5:27 PM, Natanael Copa wrote: > > Since we are sort of stuck with this, I suggest that we establish a > > working group of 4 people that together comes up with a modified or new > > proposal. > > > > I suggest Chloe is one of those and I have a candidate of someone that > > can be an external, neutral expert with experience of this process from > > other distros. > > I have no problems with this. > If it takes more people and more time to get the proposal to a > reasonably optimal state, then that's just what we'll have to do. > I do think we're reasonably close to that point, but I've also had that > belief previously (and it has been wrong multiple times now). > > > It would be good to have two more with at least one long timer. > > I would like to stress that last part: > Having someone that's been with the project for a long time should > guarantee that the zeitgeist of the project is adequately represented. > It's uncertain why this hasn't been the case so far (with you being an > active participant, and several others such as Daniel tossing ideas), > but hopefully having them be on a de-facto board that's handling this > will remedy that situation. FWIW if volunteers are still required, I could volunteer, though (as noted in other email) I'm a n00b so also happy to defer to pretty much anyone else :) 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? 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? 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. (*) for want of a better name for now. 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. Thanks! -- Richard Mortier mort@cantab.net --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---