GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Matt S Trout-2
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 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 be recorded in a RESOLUTIONS file maintained next
to this document.

=end GOVERNANCE

What say ye?

--
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Darin McBride
> 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.

In the interests of "stability" ... I'd suggest:

----

Each non-VM LS may post +1, -1 or abstain (which can cancel out a previous +1
or -1 vote).  The last vote posted is that user's final vote.  The aggregate of
those from the LAV will be -1 unless the total +1s exceed the -1s by at least
10%, in which case it is +1.

All -1s, whether from VM or non-VM, SHOULD include a reason, as in what is
preventing them from voting +1, so that patches to that effect could be
proposed.

----

The first paragraph here introduces a mild bias towards caution.  The second
introduces a mild bias towards progress (which is not the same as change).  
Note that the abstain here is slightly based on the "=0" option for voting on
perlmonks - before that was introduced, someone could accidentally click on a
++ or -- and have no way to undo that click without reloading the page prior
to submitting other votes.

And thus, my vote for your proposal, Matt, is: "-1, because it's missing these
modifications."  :)

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Ashley Pond V
In reply to this post by Matt S Trout-2
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?

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.

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Matt S Trout-2
In reply to this post by Darin McBride
On Tue, Oct 18, 2016 at 11:08:59AM -0600, Darin McBride wrote:

> > 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.
>
> In the interests of "stability" ... I'd suggest:
>
> ----
>
> Each non-VM LS may post +1, -1 or abstain (which can cancel out a previous +1
> or -1 vote).  The last vote posted is that user's final vote.  The aggregate of
> those from the LAV will be -1 unless the total +1s exceed the -1s by at least
> 10%, in which case it is +1.

That makes the existing rules harder to make more restrictive.

Are you sure you want this in the bootstrap version? It would seem more
logical to me to introduce a proposal to make this adjustment six months
in or so, no?
 
> All -1s, whether from VM or non-VM, SHOULD include a reason, as in what is
> preventing them from voting +1, so that patches to that effect could be
> proposed.

Right, so, that's common politeness to my mind, but seems trivial to amend
in afterwards.

> The first paragraph here introduces a mild bias towards caution.  The second
> introduces a mild bias towards progress (which is not the same as change).  
> Note that the abstain here is slightly based on the "=0" option for voting on
> perlmonks - before that was introduced, someone could accidentally click on a
> ++ or -- and have no way to undo that click without reloading the page prior
> to submitting other votes.

Mmm. Right, ok, explicit retraction/change of vote stuff is probably worth
having.
 
> And thus, my vote for your proposal, Matt, is: "-1, because it's missing these
> modifications."  :)

Basically: Given these modifications are all minor tweaks to things the
proposal explicitly renders tweakable, I'm inclined to ask - why do you believe
having me making the changes you desire unilaterally would be more in the
spirit of this proposal than letting it go forwards and proposing your
amendments in the normal way afterwards?

I mean, I can totally tweak the document before it's finalised. But I can't
see what that gains over "present these as amendments afterwards" ?

(I'm really not trying to be snarky here, much though 'not snarky' doesn't
exactly come naturally to me ;)

--
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Matt S Trout-2
In reply to this post by Ashley Pond V
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.

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.
 
> 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.

--
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Leo Lapworth
In reply to this post by Matt S Trout-2
On 18 October 2016 at 17:51, Matt S Trout <[hidden email]> 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.

Leo

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

John Stoffel
In reply to this post by Ashley Pond V

Ashley> This starts to feel like a corporate process that will be
Ashley> tuned out by what little community participates. Will more
Ashley> than two or three users engage with this? Will they follow the
Ashley> code closely enough to have a valid opinion?

Hear hear!  I'm a user, not a developer.  So why should I get much of
a vote even though I'm on the list?  

Ashley> As far as stability goes, I'd like to see—actually, I'd like
Ashley> to insist upon but I'm not a core dev so don't have the
Ashley> right—a performance benchmark in the dist of the last few
Ashley> releases so it's clear when and what code causes a
Ashley> change. DBIC won some extremely welcome performance gains
Ashley> under RIBASUSHI and I don’t think it would be reasonable to
Ashley> ever give them up for the sake of new development.

I'm just amused by all the verbiage flowing by, but no code, cries for
help with the code, etc.  If it's all such a pain in the ass, just
free what's here and fork the project.  Sheesh... that's the open
source way.

John

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Matt S Trout-2
On Tue, Oct 18, 2016 at 02:28:09PM -0400, John Stoffel wrote:
> Hear hear!  I'm a user, not a developer.  So why should I get much of
> a vote even though I'm on the list?  

Because your opinions on prioritisation matter to the developers.
 
> I'm just amused by all the verbiage flowing by, but no code, cries for
> help with the code, etc.  If it's all such a pain in the ass, just
> free what's here and fork the project.  Sheesh... that's the open
> source way.

Forcing the entire ecosystem to fork to deal with that didn't strike me as
a great way to maximise time spent producing actually useful code either.

--
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

David Precious
In reply to this post by John Stoffel
On Tue, 18 Oct 2016 14:28:09 -0400
"John Stoffel" <[hidden email]> wrote:

>
> Ashley> This starts to feel like a corporate process that will be
> Ashley> tuned out by what little community participates. Will more
> Ashley> than two or three users engage with this? Will they follow the
> Ashley> code closely enough to have a valid opinion?
>
> Hear hear!  I'm a user, not a developer.  So why should I get much of
> a vote even though I'm on the list?  

Because, at the end of the day, the software is developed for the
users, so it very much helps if the software goes in the direction that
most benefits the users, and a plan like this helps focus on what users
of the project actually want, rather than what the core developers
*think* the users want.

With regards to the idea of the "fifth seat" being filled by community
voting, it gets a +1 from me; the outlined proposals sound good, and
changes to those proposals can be made later by precisely the same
voting process.

I was going to suggest that a "steering committee" of interested users
be formed, but I'm not sure there's any value in anything more formal
than "the users on the mailing list" - after all, those on the list can
be reasonably expected to be here because they have an interest in the
project.

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Chase Whitener
Matt's suggestion seems to be the most logical course of action to me.

+1


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Matt S Trout-2
In reply to this post by Matt S Trout-2
Also remember that if you've been finding the various discussions a trifle
fraught and would prefer not to risk being yelled at for having the wrong
opinion, I believe xdg's offer to aggregate and post private feedback still
stands.

--
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

James E Keenan
In reply to this post by Matt S Trout-2
On 10/18/2016 12:51 PM, Matt S Trout wrote:
> =end GOVERNANCE
>
> What say ye?
>

This sounds like a reasonable starting point for me. +1

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Dave Cross-2
In reply to this post by Leo Lapworth
On 18/10/2016 19:03, Leo Lapworth wrote:

> On 18 October 2016 at 17:51, Matt S Trout <[hidden email]> 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.

What Leo said.

+1

Dave...


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Darin McBride
In reply to this post by Matt S Trout-2
On Tuesday October 18 2016 5:26:05 PM Matt S Trout wrote:

> On Tue, Oct 18, 2016 at 11:08:59AM -0600, Darin McBride wrote:
> > > 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.
> >
> > In the interests of "stability" ... I'd suggest:
> >
> > ----
> >
> > Each non-VM LS may post +1, -1 or abstain (which can cancel out a previous
> > +1 or -1 vote).  The last vote posted is that user's final vote.  The
> > aggregate of those from the LAV will be -1 unless the total +1s exceed
> > the -1s by at least 10%, in which case it is +1.
>
> That makes the existing rules harder to make more restrictive.

Sorry, you're right. I was more thinking about this extra hurdle exclusively
for non-dev CPAN releases.  Us users mostly don't care about the processes
used to get to the next release, but mostly only about the actual release
itself - does it break our existing code, does it offer the features we need,
does it impact performance (positively or negatively), is it released in the
necessary timeframe, etc.  The governance model is _completely_ superfluous
unless it is impacting things in actual releases.

> Are you sure you want this in the bootstrap version? It would seem more
> logical to me to introduce a proposal to make this adjustment six months
> in or so, no?

I kind of propose it in a tongue-in-cheek fashion based on itself.  That is,
if no one else agrees, then my own proposal defeats itself ;)

> > All -1s, whether from VM or non-VM, SHOULD include a reason, as in what is
> > preventing them from voting +1, so that patches to that effect could be
> > proposed.
>
> Right, so, that's common politeness to my mind, but seems trivial to amend
> in afterwards.

Rights without responsibilities always seem a bit suspect to me, so where
you're granting an explicit aggregate right to LS, it seems to me that it
should come with an explicit aggregate responsibility.

> > The first paragraph here introduces a mild bias towards caution.  The
> > second introduces a mild bias towards progress (which is not the same as
> > change). Note that the abstain here is slightly based on the "=0" option
> > for voting on perlmonks - before that was introduced, someone could
> > accidentally click on a ++ or -- and have no way to undo that click
> > without reloading the page prior to submitting other votes.
>
> Mmm. Right, ok, explicit retraction/change of vote stuff is probably worth
> having.

I'm sure that if this actually becomes really engaging, someone will put up a
web page somewhere for managing votes instead of on-list... but who knows :)

> > And thus, my vote for your proposal, Matt, is: "-1, because it's missing
> > these modifications."  :)
>
> Basically: Given these modifications are all minor tweaks to things the
> proposal explicitly renders tweakable, I'm inclined to ask - why do you
> believe having me making the changes you desire unilaterally would be more
> in the spirit of this proposal than letting it go forwards and proposing
> your amendments in the normal way afterwards?

I didn't suggest it be done unilaterally.  Other LS users can agree or
disagree with my suggestions, and you can use that to inform your changes, if
any.

> I mean, I can totally tweak the document before it's finalised. But I can't
> see what that gains over "present these as amendments afterwards" ?
>
> (I'm really not trying to be snarky here, much though 'not snarky' doesn't
> exactly come naturally to me ;)

I thought that adding some bias against _non-dev releases_ that this would be
more in line with riba's concerns about the stability DBIC's users care about.  
If no one else is concerned, then their +1s outweigh my -1, and, by my own
proposal's rules, my suggestions are mooted :)

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Darren Duncan
In reply to this post by Matt S Trout-2
On 2016-10-18 9:51 AM, Matt S Trout wrote:
> What say ye?

I don't have much to add that hasn't been said by others.

Assuming that "modifying the rules" includes "modifying the list of voting
members" ...

+1

I agree that it would be good to get this document into the repository and use
it as a starting point for a more official governance.

That should help prevent or unstick some analysis paralysis, as it would give a
reasonably safe starting place, where uncontroversial things have been
formalized, and anything needing changing about governance can be changed
without holding up the other stuff.

As an initial followup, I propose talking with the remainder of Peter's EXAMPLE
preferred core team, those not also in Matt's list, namely HAARG and SYSPETE in
that order, and see if they would be interested in being Voting Members.

-- Darren Duncan


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Matt S Trout-2
On Tue, Oct 18, 2016 at 12:35:23PM -0700, Darren Duncan wrote:
> On 2016-10-18 9:51 AM, Matt S Trout wrote:
> >What say ye?
>
> I don't have much to add that hasn't been said by others.
>
> Assuming that "modifying the rules" includes "modifying the list of
> voting members" ...

"Amend this document" absolutely includes the lists, hence the comment
about PAUSE perms.
 

> +1
>
> I agree that it would be good to get this document into the
> repository and use it as a starting point for a more official
> governance.
>
> That should help prevent or unstick some analysis paralysis, as it
> would give a reasonably safe starting place, where uncontroversial
> things have been formalized, and anything needing changing about
> governance can be changed without holding up the other stuff.

That was basically the ideal. Minimum Viable Governance.
 
> As an initial followup, I propose talking with the remainder of
> Peter's EXAMPLE preferred core team, those not also in Matt's list,
> namely HAARG and SYSPETE in that order, and see if they would be
> interested in being Voting Members.

This is among the list of possibilities I had in mind enabling as I
figured out the Nomic-like bits. But I figured sticking with the initial
list I had meant we could figure that part out later rather than it
becoming one more axis along which bikeshedding could occur now.

--
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Chase Whitener
In reply to this post by Matt S Trout-2
This sounds like a great starting point, Matt. Let's get on with it!

+1

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Wallace Reis-3
In reply to this post by Leo Lapworth
On October 18, 2016 at 4:04:17 PM, Leo Lapworth ([hidden email]) 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 # this pretty much summarizes my position.

Cheers!

--
Wallace Reis

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Chase Whitener
In reply to this post by Matt S Trout-2
Sorry about the duplicate vote. I accidentally put my first one in the midst of a bunch of other replies and wanted this one to be on the main topic thread to not get lost.

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Joel Berger
In reply to this post by Matt S Trout-2
Generally I'm +1 on this proposal. Just a few notes below:

On Tue, Oct 18, 2016 at 3:12 PM Matt S Trout <[hidden email]> 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.

I think that while making a non-dev release is the most important thing, merging a branch/PR is likely to be the place that contention actually happens.
Would you consider adding this as a votable topic?
 

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.


In Mojolicious, we have the problem of as core contributors have started to move on in life, they are still on the team but become less responsive.
In the case of this system, where votes are required for action, I do worry that you could find yourself in a place where nothing happens and it is unresolvable simply because you can't get the votes to make the changes to the core team to make more changes.
Then again, if the core member realizes this is happening it can be headed off at the pass earlier.
Just me being a little cautious :-P
 
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 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 be recorded in a RESOLUTIONS file maintained next
to this document.

=end GOVERNANCE

What say ye?

--
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@...

_______________________________________________
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@...
12
Loading...