<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div><span>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. </span></div> <div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font size="2" face="Arial"> On Tuesday, October 18, 2016 11:52 AM, Matt S Trout <mst@shadowcat.co.uk> wrote:<br></font></div> <br><br> <div class="y_msg_container">So, given the balance of comments so far has been in favour of my original<br>suggested core list, and given neither the mailing list members nor riba have<br>proposed a fifth, it occurred to me that there's a potentially better way<br>forwards.<br><br>Ladies, gentlemen, and mongers, the fifth "seat" is going to be the user<br>base, as represented by the subscribers to this mailing list.<br><br>Of course, for this to work, we need a voting system. And for said voting<br>system to not be a colossal pain in the arse now or later, it needs to be<br>both minimalist and flexible, while still providing checks and balances.<br><br>Obviously, being a massive nerd, the logical solution to this was to steal<br>the core concept from <a href="http://enwp.org/Nomic" target="_blank">http://enwp.org/Nomic </a>- so our bootstrap governance<br>is going to be a set of rules for voting, with a built in mechanism for<br>using those rules to modify the rules.<br><br>I've kept the initial list of "things that must have a vote" to just<br>'making a non-dev release' and 'modifying the rules' on the assumptions that<br>(a) rolling back bureaucracy is generally harder than creating it (2) any<br>attempt at guessing up front what we need would likely be a failure (iii)<br>provided you can vote for "undo X and don't do it again" (which given a<br>versioned repository is rather built in for most things) people can be<br>trusted to make reasonable choices about which Xes won't trigger that.<br><br>Possibly I've misjudged a bunch of things here. Possibly we'll only realise<br>that later. However, given the system is built to be evolved as we go, I<br>think this is an acceptable starting point, and can be evolved into exactly<br>as much of a checks-and-balances system as turns out to be desirable to<br>the userbase.<br><br>Oh, and I already ran it past castaway/ilmari/frew and made the relevant<br>tweaks as a result of their feedback (because it's nice to have consensus<br>and I figured "start as you mean to go on" would be a good plan).<br><br>As such, I hereby propose that, assuming the community agrees, the following<br>document be entered into the repository under the filename GOVERNANCE, and<br>that the PAUSE administration then update permissions accordingly:<br><br>=begin GOVERNANCE<br><br>DBIx::Class Core Team and Voting System<br><br>Non normative section:<br><br>DBIx::Class originally operated under a BDFL system, but one where it was<br>expected that an informal core team would be maintained, and that where<br>consensus could not be pre-assumed, the core team and/or the user base<br>would be consulted publically such that measured decisions could be made.<br><br>This document is intended to formalise a form of this system, while still<br>providing room for the system to adapt later as required.<br><br>It is intended that this system provides confidence to the user base that<br>decisions will be made in the open and that their wishes will be taken into<br>account.<br><br>It is also intended that this system allows business as usual to happen<br>without unnecessary red tape.<br><br>It is not intended that this system becomes the primary decision making<br>process in and of itself; instead, it is intended that this system is used<br>to ratify consensus as formed by discussion, and only sparingly as a tie<br>breaking system when consensus cannot be reached.<br><br>Normative section:<br><br>Terms: VM - Voting Member - part of the benevolent dictatorship<br> LS - List Subscriber - a subscriber to the mailing list<br> LAV - List Aggregate Vote - the aggregate vote of the non-VM LSes<br><br>Voting Members are:<br><br> Matt S Trout (mst) cpan:MSTROUT<br> Dagfinn Ilmari Mansaker (ilmari) cpan:ILMARI<br> Frew Schmidt (frew) cpan:FREW<br> Jess Robinson (castaway) cpan:JROBINSON<br><br>PAUSE release perms are to be held by:<br><br> Matt S Trout (mst) cpan:MSTROUT<br> Dagfinn Ilmari Mansaker (ilmari) cpan:ILMARI<br> Frew Schmidt (frew) cpan:FRIOUX<br> Jess Robinson (castaway) cpan:JROBINSON<br><br>(the above two lists may or may not be identical at any given time)<br><br>A resolution must be proposed and then successfully voted upon to:<br><br> - Make a PAUSE-indexed (i.e. non-dev) release of DBIx::Class<br> - Amend this document<br><br>A resolution that amends the 'PAUSE release perms' list is to be assumed to<br>also intend the permission within PAUSE itself to be updated accordingly.<br><br>Adding or removing entries from the list of situations requiring resolutions<br>is absolutely a valid topic for resolutions.<br><br>A resolution may be proposed for reasons including, but not limited to:<br><br> - Force/revert/block a branch merge<br> - Add/remove a commit bit<br> - Resolve a design discussion<br> - Anything you like, but if it gets -5 maybe reconsider your choices<br><br>Merges and similar actions that do not have a resolution attached may be made<br>at the discretion of those with ability to do so, but it is expected that in<br>any case that might involve non-trivial discussion a proposal will be made.<br><br>Having a resolution immediately proposed to revert a merge is expected to be<br>taken as a hint to be more careful in future.<br><br>Rules that restrict this "ask unless you're sure" trust-by-default position<br>are also absolutely a valid topic for resolutions.<br><br>Resolution proposal:<br><br>A resolution is proposed by starting a new thread entitled 'PROPOSAL: ...'.<br><br>A resolution must be seconded before it is voted upon.<br><br>If a VM makes or seconds a proposal, they are required to abstain from<br>voting upon it.<br><br>If a non-VM LS makes or seconds a proposal, no such restriction applies.<br><br>Resolution voting:<br><br>Once a proposal is seconded, the initial proposer may start a new thread<br>entitled 'VOTE: ...' (voting does not automatically begin after seconding<br>in case other feedback leads the proposer to wish to alter and re-present<br>their proposal).<br><br>Each VM may cast one vote, either +1, -1 or abstain.<br><br>Each non-VM LS may post +1 or -1, and the aggregate of those form the LAV,<br>which is +1 if the total is positive, -1 if negative, or abstain if 0.<br><br>Voting closes after 72 hours of the last vote by anybody or after the<br>outcome can no longer be affected by further votes.<br><br>A resolution passes if it has a positive total vote count and at least one<br>VM has voted.<br><br>Once a resolution has passed, the resolution will be carried out by those with<br>the power to do so. It will not be reverted without a new resolution<br>amending or reversing the decision of the previous once.<br><br>Passed resolutions will be recorded in a RESOLUTIONS file maintained next<br>to this document.<br><br>=end GOVERNANCE<br><br>What say ye?<br><br>-- <br>Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue<br><br><a href="http://shadowcat.co.uk/blog/matt-s-trout/" target="_blank">http://shadowcat.co.uk/blog/matt-s-trout/ </a> <a href="http://twitter.com/shadowcat_mst/" target="_blank">http://twitter.com/shadowcat_mst/</a><br><br>Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN<br>commercial support, training and consultancy packages could help your team.<br><br>_______________________________________________<br>List: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class</a><br>IRC: irc.perl.org#dbix-class<br>SVN: <a href="http://dev.catalyst.perl.org/repos/bast/DBIx-Class/" target="_blank">http://dev.catalyst.perl.org/repos/bast/DBIx-Class/</a><br>Searchable Archive: <a href="http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk" target="_blank">http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk</a><br><br><br></div> </div> </div> </div></div></body></html>