1) Add better support for HTTP Methods, and alternative body parsers (such as JSON and XML) to Catalyst core. Right now this stuff is in extensions but given how much people using server side frameworks for doing AJAX, I believe it should be core, since it would be faster, easier for newbies and we could take advantage of the deep integration to better support RESTfulness, (like properly setting the accept type and the http options headers)
2) I'd love to extract the database sandboxing feature from DBIC::Migration and Test::DBIx::Class into something stand alone, so that people that don't want to drink all my koolaide could at least benefit from easy developer level database sandboxes
These are two things off the top of my head that I can think of. These are things I am working on regardless but if there was some money behind it I could justify spending much more time, (and I'd have time to improve the docs and tests, stuff I'm tempted to skimp on when I am exclusively on my own time.
Are these things grant worthy?
Johnnap
]]>I would recommend people with interesting ideas submit a $3k project and try to aim for doing it in a few weekends. Perhaps propose the grant for your local perlmongers and make a project night of doing it in one (or just a few) nights, then share the proceeds.
Alberto, perhaps the application process could be streamlined? Maybe a github with README which addresses why it exists and current progress could supplement a tiny application asking for the money and the timeframe? Most of these projects will be itches that author's are like to scratch at some point and are likey scratching already but need some help ($) to stay focused.
A few months back run4flat and I floated an idea by email to TPF suggesting microgrants (bounties) placed on known nits. TPF would publish a list of nits and their monetary value. The first claimant would get the bounty. (Maybe this feature could be added to play-perl?)
Overall the grant process is useful, the question is how to get more people to participate.
]]>Sounds interesting, and completely in line with my future play-perl plans. But I'm not sure monetary bounties for tasks is a healthy motivator for volunteers. Science says otherwise.
My personal opinion regarding Perl Foundation money pool is this: spend it for marketing purposes. Buy Google Ads, sponsor conferences, print tons of posters and spread them at schools and colleges. I believe that would be much more useful than paying for grants to those who already do the hard work for free and are intrinsically motivated.
(I'm not sure if TPF donation rules allow this kind of usage. Do they?)
Unfortunately, I am not sure if I can argue that my extensions would be widely adopted. I suppose I could put in a grant, since it's now or never, but these are the reasons I hadn't done so yet.
]]>If it doesn't, it should. This is one of the places where we need the most help right now, IMHO.
]]>I live in a spot too expensive at the moment..
]]>
This isn't stated clearly anywhere that I can find. So I'm going to assume that the purpose of the grant is roughly "to enable work beneficial to Perl which wouldn't have happened otherwise".
Who are the grants aimed at?
This isn't totally obvious either. But, assuming that it's for developers already reasonably skilled in Perl, then pretty much everyone I've met is either in full time employment ("permanent" or contract), or full time consulting, their work is their principal form of income, and they don't have massive amounts of spare time.
Which means, I think that it makes sense to consider grants in terms of the above two. In the most base terms - would I want to apply for a grant?
So, what offer is the grants committee making me?
The assumption seems to be that money can be traded for developer time. This
is reasonable in the general case. But consider that we're aiming at full
time employees, or full time consultants. Is a grant supposed to be something
instead of existing work? Or something as well as existing work.
So,
This has taken a lot of fun out of it.
And is the money really a motivation? For the calibre of people one would
hope to attract, $3000 is not a massive amount of money. If they do need
$3000, then there are usually easier ways to earn it. (Overtime, if
available. On call, if available and pays a premium. Contract commercially
outside "work" time.)
So I'm not convinced that the grants system, as set up, really is that useful.
The one immediate change which might make a difference and I think should be
tried is to remove the quarterly call and implicit structural delay, and
instead process grant applications far more frequently, even as they arrive.
Yes, this might mean that a grant application "now" uses the last funds,
preventing acceptance of a better grant application two weeks later. But,
given that for the past 6 months there have been zero applications, this
doesn't look like it will be a problem.
About the only category of people for whom the timescales and money involved
might make sense is students looking for a summer job. Google Summer of Code
pays $4500 (in stages). If once again Google is unable to accept TPF as a
mentoring organisation, then I think that TPF should try to run its own using
the existing grants committee setup to vet and approve the mentors' recommended
student candidates, and sign off payments when they and mentors are happy that
work has been done.
I have most of my deliverables, but Mac is being such a problem that I don't know for sure if I am going to get a fully satisfactory answer; should I declare defeat? I think eventually I can figure something out, perhaps with the help of CPAN testers; should I preemptively declare victory. Having to answer to someone is both motivation (useful) and pressure (possible not so useful).
I also want to concur with Nick about the lag. I think that many more people, seeing a coming gap in time might want to take advantage, but it means that they would have to (a) have an idea about an itch in advance (b) not accidentally scratch it too early.
Some more "agile" system would likely produce more dividends. Whether quick turnaround of individual proposals or pre-established grants awaiting claimants (bounties, see above) I think Nick is right, the lag is a major problem.
]]>Of course there is a lot more work that can be done, I'll look into applying for a grant for next quarter (or sooner if the rules change).
]]>As Nicholas pointed out, the grants system is a bit arcane, and takes a fair amount of work and waiting, just to apply.
To everyone else: You'll never know if your idea/plan was good enough for a grant if you don't apply! Don't assume it isnt, ask!
]]>To be financed with grant there must really be a tangible, important benefit to community at large that cannot be achieved without grant. And this criteria leaves VERY FEW things appropriate to be financed with grant.
And most important such thing is a highly skilled work of core development (in light of recent development that interpreters of other languages have underwent, e.g. that spectacular JavaScript performance race, Perl 5 still has a room for improvement), but there is already Perl 5 maintenance fund dedicated to this end. Apart from that there are very few things worth financing with grants that will be the right use of scarce contributed funds, and people understand that, so probably that is why there are very few or no proposals.
And that is how it really should be. Only the best use of funds will motivate people to contribute money in the first place. If funds are spent on minor projects away from core needs of the community, we soon end up with no monetary contributions, as contributors will see no results that their money are worth of. So the general principle is that grants should be spend on something that contributors of most funds would approve.
This is perfectly OK to support development with funds raised from Perl community contributions. The only requirement is spending those funds to make (or foster) real technological advances of Perl (since we all depend on it), not just spend money on Perl projects.
]]>One feature you may find useful is this:
my %types; Types::Standard->import( { into => \%types }, qw( Str ArrayRef ), ); Types::XSD->import( { into => \%types }, "NonNegativeInteger" => { -as => "NNInt" }, ); my $check = Type::Params::compile( $types{Str}->(), $types{ArrayRef}->([ $types{NNInt}->(), ]), );
... so you can stuff all the type constraints that a package needs into a hash, and use them like that. I don't know how useful that might be.
]]>