Time to figure out what we need to do to get moving again. Note that I'm going to list a bunch of things below, with brief notes on each one - as you reply, please adjust the subject line to indicate which one you're responding to, and separate replies for each response. Hopefully that'll give us a reasonable balance between keeping things clear and not ending up in [1/27] territory.
* Getting master released riba said that he believed that what's currently there is releasable as-is, but given the rest of us aren't as familiar with the changes he's made and in a spirit of "belt and braces" I think we should ship a dev release first. Plus it's probably a good idea for at least a couple of the VMs to go through the log and familiarise ourselves with the shape of the changes before we put out a PAUSE indexed released with these commits. * Moderation policy Previously, DBIx::Class spaces - here, the mailing list, bug trackers - have basically been moderated by a principle of "everybody is expected to be an adult and if you don't manage that expect mst to mallet you". I've no particular objection to keeping it that way, it's not like we've needed it very often anyway - but given different definitions of civility were touched upon in the governance discussions, it seems worth considering doing things a little more formally. Roughly, the question comes down to - do we want to formalize moderation now, or do we want to leave things informal for the moment under the assumption that we can always formalize via proposal later if informal becomes an issue? * Branches and PRs and tickets, oh my We're going to need a triage pass on all three of these to figure out what's active, what's ancient, and what's "we think this is a riba work in progress but it's above our pay level right now". There's likely quite a bit of effort involved here so I think we'll want to crowdsource at least the first pass; who'd be interested in helping out, and does anybody have any flashes of inspiration as to how best to co-ordinate this? (in case anybody's wondering, I'm intending to attic the dq2 branches since I don't believe they'll ever end up merge-worthy in their current form) * Feature planning I have the odd idea for things that might potentially be of interest to people as features once we've got current master shipped, but that's definitely a 'might' and I regard everybody to have a stake in the direction at this point. I suspect it's probably worth having a 'request for feature requests' thread, and maybe also mirroring that somewhere else (a github issue? a blog post? all of the above plus a bat signal?). * Stability protection I also suspect that given people are/were significantly interested in stability/performance of the existing API, often more so than getting any particular extension thereof, I'd like to here people's thoughts as to how we measure that - stability is probably mostly covered by the ridiculous number of tests that riba added plus a little common sense, but I wouldn't object to additional suggestions. * Speeeeeeeeeeeeeeeeeeeed Performance, on the other hand, requires benchmarks that we believe reflect real world use and allow us to guide where we try and optimise and where we worry about pessimisations. I have a few ideas of my own, but I'd love to hear from people who're concerned about perl-side performance as to what they think would constitute a solid set of benchmarks. I'm fairly convinced that crowdsourcing this is going to be the best way to approximate a representative set of benchmarks to monitor, though meta-crowdsourcing where you suggest other approaches is completely welcome. * Conflicts of interest DBIx::Class has had a number of features over its history sponsored by various companies, whether directly by their staff being paid to build them or indirectly via Shadowcat and others; such things have always, so far as I've been involved, been merged or not merged on the merits and neither the sponsors nor the userbase have ever had an issue. On the other hand, we're trying to formalise things a little bit, and it's been clear from prior discussions that riba at least isn't entirely comfortable with such things being any less than explicit - so again the question becomes "do we leave it informal and assume people will behave sensibly knowing that it can be formalised by proposal any time people want to, or do we formalise it pre-emptively to ensure expectations are clear and explicit?" * Any other business? If there's anything organisational/immediate that you think is worth discussing, including possible amendments/refinements of the governance system, please do whack a note in under this subheading. Also this gives me a get out clause if I realise tomorrow I missed out one of the categories I'd intended to include, or if my original set of intentions was missing an entry outright. (and, finally, thank you for bearing with me - had to get back up to speed with other things after the ructions of late last year before I could give DBIC a useful amount of attention) -- 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