[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.berger at 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 <mst at 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 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 DBIx::Class
>   - Amend this document
>
> A resolution that amends the 'PAUSE release perms' list is to be assumed to
> also intend the permission within PAUSE itself to be updated accordingly.
>
> Adding or removing entries from the list of situations requiring
> resolutions
> is absolutely a valid topic for resolutions.
>
> A resolution may be proposed for reasons including, but not limited to:
>
>   - Force/revert/block a branch merge
>   - Add/remove a commit bit
>   - Resolve a design discussion
>   - Anything you like, but if it gets -5 maybe reconsider your choices
>
> Merges and similar actions that do not have a resolution attached may be
> made
> at the discretion of those with ability to do so, but it is expected that
> in
> any case that might involve non-trivial discussion a proposal will be made.
>
> Having a resolution immediately proposed to revert a merge is expected to
> be
> taken as a hint to be more careful in future.
>
> Rules that restrict this "ask unless you're sure" trust-by-default position
> are also absolutely a valid topic for resolutions.
>
> Resolution proposal:
>
> A resolution is proposed by starting a new thread entitled 'PROPOSAL: ...'.
>
> A resolution must be seconded before it is voted upon.
>
> If a VM makes or seconds a proposal, they are required to abstain from
> voting upon it.
>
> If a non-VM LS makes or seconds a proposal, no such restriction applies.
>
> Resolution voting:
>
> Once a proposal is seconded, the initial proposer may start a new thread
> entitled 'VOTE: ...' (voting does not automatically begin after seconding
> in case other feedback leads the proposer to wish to alter and re-present
> their proposal).
>
> Each VM may cast one vote, either +1, -1 or abstain.
>
> Each non-VM LS may post +1 or -1, and the aggregate of those form the LAV,
> which is +1 if the total is positive, -1 if negative, or abstain if 0.
>
> Voting closes after 72 hours of the last vote by anybody or after the
> outcome can no longer be affected by further votes.
>
> A resolution passes if it has a positive total vote count and at least one
> VM has voted.
>
> Once a resolution has passed, the resolution will be carried out by those
> with
> the power to do so.  It will not be reverted without a new resolution
> amending or reversing the decision of the previous once.
>
> Passed resolutions will be recorded in a RESOLUTIONS file maintained next
> to this document.
>
> =end GOVERNANCE
>
> What say ye?
>
> --
> Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a
> clue
>
> http://shadowcat.co.uk/blog/matt-s-trout/
> http://twitter.com/shadowcat_mst/
>
> Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
> commercial support, training and consultancy packages could help your team.
>
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive:
> http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20161018/cc82e9a0/attachment.htm>