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 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 > >
_______________________________________________ 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