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