There've been a number of suggested modifications. Some of them I like, some of them I don't.
However, updating this document with just the ones I like seems like it would rather be missing the point of a document built to encourage seeking userbase consensus. So, instead, I update my proposal only by adding one sentence: "This document is currently in bootstrap phase, and as such no merges will be made to master or blead until this sentence is removed." This way, we can thrash out the pre-launch changes by running the various suggestions made in this thread through the proposal system, and then once we're done with that, remove that sentence via proposal and move forwards. Anybody who wishes to change their vote as a result of this, please reply here doing so. =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: This document is currently in bootstrap phase, and as such no merges will be made to master or blead until this sentence is removed. 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 -- 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