Help Me Write the next Perl Catalyst Community Poll!

Hello Catalyst Developers!

Its getting to be that time of year again.  Here in the Northern Hemisphere we are trending toward the Fall and with the waning of 2013 I find myself reflecting on what has been done, not done and if its all ok really.  In light of that I'd like to sent around a new Poll, similar to the one we did a little more than a year ago.

To help remind you, here's a link to that poll from 2012.

For 2013 I want to add a few question, and possible drop some.  So, here's your chance to help me shape the poll!  What questions would you like to be asked?  What questions would you like answers from your peers?  Which questions should definately be asked again and what should be dropped or otherwise altered?

Somethings I am thinking about...

I'd like to drill down into the whole 'barriers to contribution' thing.  And I'm trying to find some creative ways to engage our diverse community.  For examples, all my blogs are in English, and I wonder if that is hurting...   Or perhaps we should get together leaders from companies that are using Catalyst and see if we can convince them to give their programmers some time to kick in?

Ultimately I am trying to figure out if there's tasks out there people are into seeing done enough, or is the roadmap just not interesting and compellng.

Some stuff I'd like to ask about...

As we consider what changes the next major release of Catalyst will bring, (call it Cat6 or Cat7, whatever), there's a growing thought that we should take the opportunity to do some cleanup and removal of long deprecated or disused stuff.  This of course would represent the first version of Catalyst to proposal possible significant backward compatibility problems.  One thought I have is to have a 'Catalyast5.9 "virtualmachine"' or similar embedded into Catalyst6 architecture so that you could transistion in parts, similar to how Apple embedded support for pre OSX.  I think this could be done since Catalyst is now through and through PSGI (I would envision the pre Catalyst6 layer as middleware).  However  I am not sure the best way to present the idea and would love to get early 'pre poll' feedback on the thought.

Thanks everyone.  Participation is mandatory ;)

Comments

[n0body]

I'm down with breaking backwards compatibility, you've got to break a few eggs to make a cake, as they say. as for contributing, I'm planning on it, but I've just moved country, house and job, so things are a little up in the air atm!

[Caleb Cushing]

I agree with @n0body. I stopped contributing because (outside of due to increasing lack of time, and lack of need for a framework in general) I did not find catalyst to be what I needed, and in the one case where my former employer was looking for a framework, I could not sell them on Catalyst.

Things you should put in the survey ( which of these features do you want next, vote for 3 of whatever maybe ). You can represent backwards compatibility changes with this.

Better routing, Chained just had too many weirdisms (concept isn't bad but it was buggy in a way that only breaking backcompat could fix). Also perhaps centralized routing for new people to get started with.

I want Dependency Injection (Bread::Board++) Not as a replacement for config though, that is not how DI should be used (I should probably volunteer for this as according to Stevan I'm one of a handful that understands, but Tuits). I'd start this one by just making Catalyst use it under the hood, worry about making it nice for users later.

[DP]

I agree with both comments above. If the price to make it better framework is back compatibility, I would vote for that. Making things easier, would (hopefully) bring more new contributors.
Making the async stuff possible and better support to easily create RESTful APIs in the latest releases should also be step forward.