[Dbix-class] Fwd: Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

[Darin McBride]

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 <perigrin at prather.org>
> >>> Date: Oct 18, 2016 at 11:56 PM
> >>> To: DBIx::Class user and developer list <dbix-class at 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.
> >>> 
> >>> ----
> > 
> > +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 :) )