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

[John Napiorkowski]

FWIW I think the idea of having a 5th user base seat is a great idea and I'd be happy to see that idea in other projects as well.  

    On Tuesday, October 18, 2016 11:52 AM, 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.

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.

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/20161019/edcf0707/attachment-0001.htm>