On Fri, 12 Apr 2019 at 01:07, Chloe Kudryavtsev <toast_at_toastin.space> 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
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.
Received on Fri Apr 12 2019 - 17:32:25 UTC