>> From: Chris Prather <perig...@prather.org>
>> Date: Oct 18, 2016 at 11:56 PM
>> To: DBIx::Class user and developer list <firstname.lastname@example.org>
>> 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
>> 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.
Searchable Archive: http://email@example.com