I suck at email and this got bounced initially. -Chris
Begin forwarded message: > > From: Chris Prather <perig...@prather.org (mailto:perig...@prather.org)> > Date: Oct 18, 2016 at 11:56 PM > To: DBIx::Class user and developer list <dbix-class@lists.scsys.co.uk > (mailto:dbix-class@lists.scsys.co.uk)> > 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. > > > > ---- > > > > This is far more than I was planning on commenting but having read as much of > all of the relvant threads as possible I don't think that the policy *as > proposed* is as conservative as it should be to properly reflect the concerns > of all members of the community who've been involved in the conversation to > date. > > > > Thanks for your time in reading my ramblings. > > > > -Chris > > > > > > > > > >
_______________________________________________ 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
