Re: [Dbix-class] GOVERNANCE: An actually concrete proposal w/bootstrap governance system
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
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 a merge is expected to
Re: [Dbix-class] GOVERNANCE: An actually concrete proposal w/bootstrap governance system
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
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
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
On Tue, Oct 18, 2016 at 05:20:14PM -0400, John Stoffel wrote: > 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. Nah. apv's cared about this project for over ten years, he's a trifle prone to being overly strong in his descriptions because he cares too much, And anyway: https://twitter.com/shadowcat_mst/status/788466933922426880 -- 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
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
> "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
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
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
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 (castaway) cpan:JROBINSON > > (the above two lis
Re: [Dbix-class] GOVERNANCE: An actually concrete proposal w/bootstrap governance system
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 DBIx::Class > - Amend this
Re: [Dbix-class] GOVERNANCE: An actually concrete proposal w/bootstrap governance system
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
