Re: [Dbix-class] GOVERNANCE: An actually concrete proposal w/bootstrap governance system

[Joel Berger]

On Tue, Oct 18, 2016 at 3:24 PM Joel Berger <joel.a.ber...@gmail.com> wrote:

> Generally I'm +1 on this proposal. Just a few notes below:
>
> On Tue, Oct 18, 2016 at 3:12 PM Matt S Trout <m...@shadowcat.co.uk> wrote:
>
> So, given the balance of comments so far has been in favour of my original
> suggested core list, and given neither the mailing list members nor riba
> have
> proposed a fifth, it occurred to me that there's a potentially better way
> forwards.
>
> Ladies, gentlemen, and mongers, the fifth "seat" is going to be the user
> base, as represented by the subscribers to this mailing list.
>
> Of course, for this to work, we need a voting system. And for said voting
> system to not be a colossal pain in the arse now or later, it needs to be
> both minimalist and flexible, while still providing checks and balances.
>
> Obviously, being a massive nerd, the logical solution to this was to steal
> the core concept from http://enwp.org/Nomic - so our bootstrap governance
> is going to be a set of rules for voting, with a built in mechanism for
> using those rules to modify the rules.
>
> I've kept the initial list of "things that must have a vote" to just
> 'making a non-dev release' and 'modifying the rules' on the assumptions
> that
> (a) rolling back bureaucracy is generally harder than creating it (2) any
> attempt at guessing up front what we need would likely be a failure (iii)
> provided you can vote for "undo X and don't do it again" (which given a
> versioned repository is rather built in for most things) people can be
> trusted to make reasonable choices about which Xes won't trigger that.
>
>
> I think that while making a non-dev release is the most important thing,
> merging a branch/PR is likely to be the place that contention actually
> happens.
> Would you consider adding this as a votable topic?
>

Oh sorry, I see that there is more in the actual body of the topic down
below.
Never mind this comment then.


>
>
>
> Possibly I've misjudged a bunch of things here. Possibly we'll only realise
> that later. However, given the system is built to be evolved as we go, I
> think this is an acceptable starting point, and can be evolved into exactly
> as much of a checks-and-balances system as turns out to be desirable to
> the userbase.
>
>
> In Mojolicious, we have the problem of as core contributors have started
> to move on in life, they are still on the team but become less responsive.
> In the case of this system, where votes are required for action, I do
> worry that you could find yourself in a place where nothing happens and it
> is unresolvable simply because you can't get the votes to make the changes
> to the core team to make more changes.
> Then again, if the core member realizes this is happening it can be headed
> off at the pass earlier.
> Just me being a little cautious :-P
>
>
> Oh, and I already ran it past castaway/ilmari/frew and made the relevant
> tweaks as a result of their feedback (because it's nice to have consensus
> and I figured "start as you mean to go on" would be a good plan).
>
> As such, I hereby propose that, assuming the community agrees, the
> following
> document be entered into the repository under the filename GOVERNANCE, and
> that the PAUSE administration then update permissions accordingly:
>
> =begin GOVERNANCE
>
> DBIx::Class Core Team and Voting System
>
> Non normative section:
>
> DBIx::Class originally operated under a BDFL system, but one where it was
> expected that an informal core team would be maintained, and that where
> consensus could not be pre-assumed, the core team and/or the user base
> would be consulted publically such that measured decisions could be made.
>
> This document is intended to formalise a form of this system, while still
> providing room for the system to adapt later as required.
>
> It is intended that this system provides confidence to the user base that
> decisions will be made in the open and that their wishes will be taken into
> account.
>
> It is also intended that this system allows business as usual to happen
> without unnecessary red tape.
>
> It is not intended that this system becomes the primary decision making
> process in and of itself; instead, it is intended that this system is used
> to ratify consensus as formed by discussion, and only sparingly as a tie
> breaking system when consensus cannot be reached.
>
> Normative section:
>
> Terms: VM - Voting Member - part of the benevolent dictatorship
>LS - List Subscriber - a subscriber to the mailing list
>LAV - List Aggregate Vote - the aggregate vote of the non-VM LSes
>
> Voting Members a

Re: [Dbix-class] GOVERNANCE: An actually concrete proposal w/bootstrap governance system

[Joel Berger]

Generally I'm +1 on this proposal. Just a few notes below:

On Tue, Oct 18, 2016 at 3:12 PM Matt S Trout  wrote:

> So, given the balance of comments so far has been in favour of my original
> suggested core list, and given neither the mailing list members nor riba
> have
> proposed a fifth, it occurred to me that there's a potentially better way
> forwards.
>
> Ladies, gentlemen, and mongers, the fifth "seat" is going to be the user
> base, as represented by the subscribers to this mailing list.
>
> Of course, for this to work, we need a voting system. And for said voting
> system to not be a colossal pain in the arse now or later, it needs to be
> both minimalist and flexible, while still providing checks and balances.
>
> Obviously, being a massive nerd, the logical solution to this was to steal
> the core concept from http://enwp.org/Nomic - so our bootstrap governance
> is going to be a set of rules for voting, with a built in mechanism for
> using those rules to modify the rules.
>
> I've kept the initial list of "things that must have a vote" to just
> 'making a non-dev release' and 'modifying the rules' on the assumptions
> that
> (a) rolling back bureaucracy is generally harder than creating it (2) any
> attempt at guessing up front what we need would likely be a failure (iii)
> provided you can vote for "undo X and don't do it again" (which given a
> versioned repository is rather built in for most things) people can be
> trusted to make reasonable choices about which Xes won't trigger that.
>

I think that while making a non-dev release is the most important thing,
merging a branch/PR is likely to be the place that contention actually
happens.
Would you consider adding this as a votable topic?


>
> Possibly I've misjudged a bunch of things here. Possibly we'll only realise
> that later. However, given the system is built to be evolved as we go, I
> think this is an acceptable starting point, and can be evolved into exactly
> as much of a checks-and-balances system as turns out to be desirable to
> the userbase.
>
>
In Mojolicious, we have the problem of as core contributors have started to
move on in life, they are still on the team but become less responsive.
In the case of this system, where votes are required for action, I do worry
that you could find yourself in a place where nothing happens and it is
unresolvable simply because you can't get the votes to make the changes to
the core team to make more changes.
Then again, if the core member realizes this is happening it can be headed
off at the pass earlier.
Just me being a little cautious :-P


> Oh, and I already ran it past castaway/ilmari/frew and made the relevant
> tweaks as a result of their feedback (because it's nice to have consensus
> and I figured "start as you mean to go on" would be a good plan).
>
> As such, I hereby propose that, assuming the community agrees, the
> following
> document be entered into the repository under the filename GOVERNANCE, and
> that the PAUSE administration then update permissions accordingly:
>
> =begin GOVERNANCE
>
> DBIx::Class Core Team and Voting System
>
> Non normative section:
>
> DBIx::Class originally operated under a BDFL system, but one where it was
> expected that an informal core team would be maintained, and that where
> consensus could not be pre-assumed, the core team and/or the user base
> would be consulted publically such that measured decisions could be made.
>
> This document is intended to formalise a form of this system, while still
> providing room for the system to adapt later as required.
>
> It is intended that this system provides confidence to the user base that
> decisions will be made in the open and that their wishes will be taken into
> account.
>
> It is also intended that this system allows business as usual to happen
> without unnecessary red tape.
>
> It is not intended that this system becomes the primary decision making
> process in and of itself; instead, it is intended that this system is used
> to ratify consensus as formed by discussion, and only sparingly as a tie
> breaking system when consensus cannot be reached.
>
> Normative section:
>
> Terms: VM - Voting Member - part of the benevolent dictatorship
>LS - List Subscriber - a subscriber to the mailing list
>LAV - List Aggregate Vote - the aggregate vote of the non-VM LSes
>
> Voting Members are:
>
>   Matt S Trout (mst) cpan:MSTROUT
>   Dagfinn Ilmari Mansaker (ilmari) cpan:ILMARI
>   Frew Schmidt (frew) cpan:FREW
>   Jess Robinson (castaway) cpan:JROBINSON
>
> PAUSE release perms are to be held by:
>
>   Matt S Trout (mst) cpan:MSTROUT
>   Dagfinn Ilmari Mansaker (ilmari) cpan:ILMARI
>   Frew Schmidt (frew) cpan:FRIOUX
>   Jess Robinson (castaway) cpan:JROBINSON
>
> (the above two lists may or may not be identical at any given time)
>
> A resolution must be proposed and then successfully voted upon to:
>
>   - Make a PAUSE-indexed (i.e. non-dev) release of