Re: [Dbix-class] GOVERNANCE: An actually concrete proposal w/bootstrap governance system
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 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
Re: [Dbix-class] GOVERNANCE: UPDATED: An actually concrete proposal w/bootstrap governance system
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 b
Re: [Dbix-class] Fwd: Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system
On Wed, Oct 19, 2016 at 12:22:07PM -0600, Darin McBride wrote: > Also, this seems to fall in line with an earlier proposal to make the fifth > person "compatibility minded" which then earned a rebuke that such things > cannot be added after the fact. However, it can - if the person in charge of > such things has an absolute veto over shipping (in this case, a non-dev CPAN > upload). > > Chris's latter two suggestions are along the line of my own, but stricter and > clearer, so I would add +1 to those suggestions as well. If you want to say > the community has a say, this puts some teeth behind it. (Suggestion #1 I > would abstain from voting on :) ) I quite like Chris' thoughts overall, but feel like adding them by modifying my proposal a-priori and effectively unilaterally-albeit-via-consultation would unfairly prejudice the parts I like over the parts I'm less keen on, so I'm going to leave the bootstrap proposal as-is. However I would note that having the voting system tweaked using the voting system as one of the first uses of the voting system is absolutely something that was supposed to be possible, and would strike me as a pretty decent validation that the self-modifying approach can at least theoretically work. -- 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
Re: [Dbix-class] Fwd: Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system
On Wednesday October 19 2016 11:20:43 AM Dave Howorth wrote: > On 2016-10-19 05:07, John SJ Anderson wrote: > >>> From: Chris Prather > >>> Date: Oct 18, 2016 at 11:56 PM > >>> To: DBIx::Class user and developer list > >>> Subject: Re: [Dbix-class] GOVERNANCE: An actually concrete proposal > >>> w/bootstrap governance system > >>> > >>> So I'm only a interested user of DBIC. I took enough DBA classes in > >>> college to make me painfully aware that I don't want to understand how > >>> DBIC does what it does. I'm just very happy it does it. > >>> > >>> I am however deeply vested in how the Perl community self-regulates, and > >>> as such I've read probably more of this thread (and the related > >>> threads) than is healthy for someone who really should be busy trying > >>> to find paying work. That said I think this Governance Policy has > >>> merit, there are only three changes I would recommend two need to be > >>> made nearly immutable at the outset to be effective, one has already > >>> been proposed and can be adopted later. > >>> > >>> > >>> > >>> 1) The list of people with PAUSE COMAINT permissions and the list of of > >>> Voting Members should always be identical. Best would be if FIRSTCOME > >>> were held in trust by some DBIC account similar to how XML permissions > >>> are held (https://metacpan.org/author/DAHUT), and everyone else on the > >>> VM list were strictly co-maint. This might be overly complicated for > >>> what is mostly symbolic reasons but it would go a long way to > >>> demonstrating the new Governance. > >>> > >>> If someone resigns from the VM then they are removed from COMAINT. > >>> > >>> 2) Voting Members and the LAV (List aggregate Vote) have unilateral veto > >>> power for any proposal. Meaning if any Voting Member or the LAV make an > >>> explicit -1 to a proposal. The Proposal as it stands *in that thread* > >>> is dead. It will need to be re-proposed in such a way that the vetoing > >>> member either assents or abstains. This protects minority voices. My > >>> preference would be to require unanimity of consent but that would IN > >>> MY OPINION simply open the process up to be gamed during it's infancy. > >>> > >>> Finally this has already been proposed but I would add my experience > >>> with the Moose community. > >>> > >>> 3) A full PROPOSAL is required to merge a topic branch into the mainline > >>> release branch. > >>> > >>> > > > > +1 to all Chris’s suggestions. > > > > john. > > I agree with Chris's observations too. It struck me that Matt's original > voting proposals would mean that the community had no effect in > practice; Chris's proposal seems to overcome that. > > So +1 to Chris's suggestions > and -1 to the original proposal as proposed. > > Cheers, Dave > > PS In constructing low-energy buildings it is vital to achieve an > excellent degree of airtightness, which is not familiar to most > builders. One way to achieve it is by nominating an 'airtightness > champion' but that only works if the champion has the power to stop work > and even order rework. I see a parallel. This is no different in most fields - when you have something of utmost importance, you assign it to someone (or some group of people), and if things don't pass their review, all work halts. We do the same thing with security at $work - if the security team doesn't sign off, it doesn't ship. Also, this seems to fall in line with an earlier proposal to make the fifth person "compatibility minded" which then earned a rebuke that such things cannot be added after the fact. However, it can - if the person in charge of such things has an absolute veto over shipping (in this case, a non-dev CPAN upload). Chris's latter two suggestions are along the line of my own, but stricter and clearer, so I would add +1 to those suggestions as well. If you want to say the community has a say, this puts some teeth behind it. (Suggestion #1 I would abstain from voting on :) ) ___ 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
Re: [Dbix-class] GOVERNANCE: An actually concrete proposal w/bootstrap governance system
I am pretty happy with either MST's original proposal or Chris Prather's modified version (if pushed would go with Chris' amendments). Nigel. ___ 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
Re: [Dbix-class] GOVERNANCE: An actually concrete proposal w/bootstrap governance system
On 18 October 2016 at 18:34, Matt S Trout wrote: > On Tue, Oct 18, 2016 at 01:24:01PM -0400, Ashley Pond V wrote: >> This starts to feel like a corporate process that will be tuned out by >> what little community participates. Will more than two or three users >> engage with this? Will they follow the code closely enough to have a >> valid opinion? > > This was as little ceremony as I could add around a list-as-fifth-slot and > still have something that seemed like it would work. > > And ... I dunno. We used to have some pretty wide ranging discussions in the > Olde Days, I'm hoping we can get back to that again. works for me. > Even if what we end up with is the list mostly just nodding through what > the core team decides, this system at least forces the core team to propose > and decide in public, so it still seems like a net win over "trust the core > team" alone. Yup. >> As far as stability goes, I'd like to see—actually, I'd like to insist >> upon but I'm not a core dev so don't have the right—a performance >> benchmark in the dist of the last few releases so it's clear when and >> what code causes a change. DBIC won some extremely welcome performance >> gains under RIBASUSHI and I don’t think it would be reasonable to ever >> give them up for the sake of new development. > > I'd love to see a decent set of benchmarks written and become a standard > thing to run before discussing a branch merge. > > I would not like to commit to "ever" because a lot of the optimisation has > involved manual inlining and unrolling of recursion, and at some point we > may hit a situation where in order to make it possible to add a feature > outside of core something needs to be un-inlined to render it subclassable > - and while riba's provided prior art for how to minimise the impact of that > there would still likely be a slight slowdown, and I think that would need > to be debated on the merits at the time. Again agreed. Sorry not much to add on these points beyond that. A. -- Aaron J Trevena, BSc Hons http://www.aarontrevena.co.uk LAMP System Integration, Development and Consulting ___ 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
Re: [Dbix-class] Fwd: Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system
On 2016-10-19 05:07, John SJ Anderson wrote: From: Chris Prather Date: Oct 18, 2016 at 11:56 PM To: DBIx::Class user and developer list Subject: Re: [Dbix-class] GOVERNANCE: An actually concrete proposal w/bootstrap governance system So I'm only a interested user of DBIC. I took enough DBA classes in college to make me painfully aware that I don't want to understand how DBIC does what it does. I'm just very happy it does it. I am however deeply vested in how the Perl community self-regulates, and as such I've read probably more of this thread (and the related threads) than is healthy for someone who really should be busy trying to find paying work. That said I think this Governance Policy has merit, there are only three changes I would recommend two need to be made nearly immutable at the outset to be effective, one has already been proposed and can be adopted later. 1) The list of people with PAUSE COMAINT permissions and the list of of Voting Members should always be identical. Best would be if FIRSTCOME were held in trust by some DBIC account similar to how XML permissions are held (https://metacpan.org/author/DAHUT), and everyone else on the VM list were strictly co-maint. This might be overly complicated for what is mostly symbolic reasons but it would go a long way to demonstrating the new Governance. If someone resigns from the VM then they are removed from COMAINT. 2) Voting Members and the LAV (List aggregate Vote) have unilateral veto power for any proposal. Meaning if any Voting Member or the LAV make an explicit -1 to a proposal. The Proposal as it stands *in that thread* is dead. It will need to be re-proposed in such a way that the vetoing member either assents or abstains. This protects minority voices. My preference would be to require unanimity of consent but that would IN MY OPINION simply open the process up to be gamed during it's infancy. Finally this has already been proposed but I would add my experience with the Moose community. 3) A full PROPOSAL is required to merge a topic branch into the mainline release branch. +1 to all Chris’s suggestions. john. I agree with Chris's observations too. It struck me that Matt's original voting proposals would mean that the community had no effect in practice; Chris's proposal seems to overcome that. So +1 to Chris's suggestions and -1 to the original proposal as proposed. Cheers, Dave PS In constructing low-energy buildings it is vital to achieve an excellent degree of airtightness, which is not familiar to most builders. One way to achieve it is by nominating an 'airtightness champion' but that only works if the champion has the power to stop work and even order rework. I see a parallel. ___ 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
Re: [Dbix-class] GOVERNANCE: An actually concrete proposal w/bootstrap governance system
On Tue, Oct 18 2016, Leo Lapworth wrote: > On 18 October 2016 at 17:51, Matt S Trout wrote: > > > =begin GOVERNANCE > > > . > > =end GOVERNANCE > > > > What say ye? > > This gets the governance issue resolved and puts in place a framework that > can evolve to fit what is needed at the time. > > +1 > > Anything more is just detail which can be added as required by the > community or core updating the governance in accordance with these rules. +1 patrick -- Patrick Meidl, Mag. Senior Expert Software Engineering IST - Institute of Science and Technology Austria Am Campus 1 A-3400 Klosterneuburg, Austria R I21.EG.115 (Building West, BT01) T +43 2243 9000 1313 E pme...@ist.ac.at W https://icp.ist.ac.at/search/users/pmeidl ___ 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
