On 2016-10-19 05:07, John SJ Anderson wrote:
From: Chris Prather <perig...@prather.org>
Date: Oct 18, 2016 at 11:56 PM
To: DBIx::Class user and developer list <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.
----
+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
