[Dbix-class] Orders of Business

[Matt S Trout]

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.