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

2016-10-31 Thread Gavin Henry
Hi all,

Just caught up with this all. Been a long time. My business is a big user
of dbic and Cataylst, so I'm eager for all to live on and be managed well.
Having worked with Matt via the community and commercially since 2005, I
and my business +1 this. It's just like creating a company board with the
non-exec director being the community.

Please let me know if anyone needs commercial backing and/or support here?

Thanks,
Gavin.
http://SureVoIP.co.uk







-- 
http://www.suretecsystems.com/services/openldap/
http://www.surevoip.co.uk
___
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

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

2016-10-19 Thread John Napiorkowski
FWIW I think the idea of having a 5th user base seat is a great idea and I'd be 
happy to see that idea in other projects as well.  

On Tuesday, October 18, 2016 11:52 AM, Matt S Trout  
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.

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 

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

2016-10-19 Thread Nigel Metheringham
I am pretty happy with either MST's original proposal or Chris Prather's
modified version (if pushed would go with Chris' amendments).

Nigel.


___
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


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

2016-10-19 Thread Aaron Trevena
On 18 October 2016 at 18:34, Matt S Trout  wrote:
> 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.

works for me.

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

Yup.

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

Again agreed.

Sorry not much to add on these points beyond that.

A.

-- 
Aaron J Trevena, BSc Hons
http://www.aarontrevena.co.uk
LAMP System Integration, Development and Consulting

___
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

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

2016-10-19 Thread Patrick Meidl
On Tue, Oct 18 2016, Leo Lapworth  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

patrick

-- 
Patrick Meidl, Mag.
Senior Expert Software Engineering

IST - Institute of Science and Technology Austria
Am Campus 1
A-3400 Klosterneuburg, Austria

R I21.EG.115 (Building West, BT01)
T +43 2243 9000 1313
E pme...@ist.ac.at
W https://icp.ist.ac.at/search/users/pmeidl



___
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


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

2016-10-18 Thread Jonathan Scott Duff
On Tue, Oct 18, 2016 at 2:58 PM, Wallace Reis  wrote:

> On October 18, 2016 at 4:04:17 PM, Leo Lapworth (l...@cuckoo.org) 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.
>

Aye, me too.  +1


-Scott


>
> 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@lists.scsys.co.uk
>
___
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

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

2016-10-18 Thread John Stoffel
> "Ashley" == Ashley Pond V  writes:

Ashley> On Tue, Oct 18, 2016 at 2:28 PM, John Stoffel  wrote:
>> 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.

Ashley> I've been involved with this project since before day one, John, and
Ashley> I've been one of the bigger evangelists for it. I *was* considering
Ashley> forking or starting over before RIBASUSHI came and started to fix the
Ashley> fallow codebase, when MST had disappeared saying only a complete
Ashley> rewrite could fix the deep problems with the codebase.

I don't the history of this package.  Nor do I really care.  But I do
recognize how hard it is, and how much work it is to keep up
maintenance of *any* open source project over the long haul.  When the
original auther stops being interested, or gets hit by a bus, or any
one of a multitude of potential problems.

And then when someone comes along and resurrects things and improves
them, it leads to feelings of accomplishment and ownership.  Nothing
unusual there.  It's when the project starts falling silent again,
that things get wonky.  

Ashley> I am not amused by any of this, least of all by your reply.

Sorry, I'm just sitting on the side lines watching all this fly by and
not really seeing much progress.  But that's ok, I'm not even a major
user or developer of the package.  I probably should have just kept my
mouth shut.

In any case, I'm just happy to see progress.

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@lists.scsys.co.uk


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

2016-10-18 Thread Matt S Trout
On Tue, Oct 18, 2016 at 04:33:19PM -0400, Ashley Pond V wrote:
> I've been involved with this project since before day one, John, and
> I've been one of the bigger evangelists for it. I *was* considering
> forking or starting over before RIBASUSHI came and started to fix the
> fallow codebase, when MST had disappeared saying only a complete
> rewrite could fix the deep problems with the codebase.

I think it's fair to say that riba saved DBIx::Class from my burnout
back in the day.

Hopefully having a more distributed system will ameliorate that risk somewhat.
 
> I am not amused by any of this, least of all by your reply.

If it's any consolation, I don't think any of the contributors involved are
having a lot of fun.

-- 
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@lists.scsys.co.uk


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

2016-10-18 Thread Ashley Pond V
On Tue, Oct 18, 2016 at 2:28 PM, John Stoffel  wrote:
> 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.

I've been involved with this project since before day one, John, and
I've been one of the bigger evangelists for it. I *was* considering
forking or starting over before RIBASUSHI came and started to fix the
fallow codebase, when MST had disappeared saying only a complete
rewrite could fix the deep problems with the codebase.

I am not amused by any of this, least of all by your reply.

___
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


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

2016-10-18 Thread Joel Berger
On Tue, Oct 18, 2016 at 3:24 PM Joel Berger  wrote:

> Generally I'm +1 on this proposal. Just a few notes below:
>
> On Tue, Oct 18, 2016 at 3:12 PM Matt S Trout  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?
>

Oh sorry, I see that there is more in the actual body of the topic down
below.
Never mind this comment then.


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

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

2016-10-18 Thread Joel Berger
Generally I'm +1 on this proposal. Just a few notes below:

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

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

2016-10-18 Thread Chase Whitener
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@lists.scsys.co.uk

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

2016-10-18 Thread Wallace Reis
On October 18, 2016 at 4:04:17 PM, Leo Lapworth (l...@cuckoo.org) 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@lists.scsys.co.uk


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

2016-10-18 Thread Chase Whitener
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@lists.scsys.co.uk

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

2016-10-18 Thread Matt S Trout
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@lists.scsys.co.uk


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

2016-10-18 Thread Darren Duncan

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@lists.scsys.co.uk


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

2016-10-18 Thread Darin McBride
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@lists.scsys.co.uk


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

2016-10-18 Thread Dave Cross

On 18/10/2016 19:03, Leo Lapworth 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.


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@lists.scsys.co.uk


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

2016-10-18 Thread James E Keenan

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@lists.scsys.co.uk


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

2016-10-18 Thread Matt S Trout
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@lists.scsys.co.uk


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

2016-10-18 Thread 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@lists.scsys.co.uk

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

2016-10-18 Thread David Precious
On Tue, 18 Oct 2016 14:28:09 -0400
"John Stoffel"  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@lists.scsys.co.uk


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

2016-10-18 Thread Matt S Trout
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@lists.scsys.co.uk


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

2016-10-18 Thread John Stoffel

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@lists.scsys.co.uk

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

2016-10-18 Thread Leo Lapworth
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.

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@lists.scsys.co.uk


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

2016-10-18 Thread Matt S Trout
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@lists.scsys.co.uk

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

2016-10-18 Thread Matt S Trout
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@lists.scsys.co.uk


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

2016-10-18 Thread Ashley Pond V
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@lists.scsys.co.uk

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

2016-10-18 Thread 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@lists.scsys.co.uk