We have five proposals to review, including the one from July.
YAPC::Asiaが目の前に迫ってきました。日本のPerl使いの皆様向けにThe Perl Foundation内のGrants Committeeの活動を紹介します。
Grants Committeeは米国非営利法人、Perl Foundation内の最大勢力を占める委員会です。
委員長は私、野崎が務めています。委員はコミュニティの代表を世界各地から集める方針を取っており、アジア・太平洋地域からは牧大輔とKaren Pauleyが選出されています。その他北米4人、欧州の4人の委員に加え、アジア・北米・欧州からGrant Managerという役職に1名ずつついており計14人の所帯です。
tpf-grants-secretary at perl-foundation.orgへどうぞ。
Earlier I wrote this blog post, which in summary says value of a Perl software project, as opposed to a Perl infrastructure project, is difficult to quantify until the software is written and used. And it often does not work nicely with our grant program where grant value has to be determined before the software exists.
For instance, if I request a $2000 grant to improve a popular Perl module's performance by 1000 times, I imagine I'll get the money provided I can demonstrate the performance improvement with some proof-of-concept code.
What if I propose to write face recognition software in Perl which finds your doppelgänger from images on the web? And if I request $5000? It's not hard to imagine your reaction will be "an interesting idea but how does it help the Perl community?"
The problem is that, while I believe this unwritten software will get attention and my website will get one million hits per day, which will help Perl reputation, I have no way to prove my website's future popularity upfront.
I'd like to propose a way to tackle with this dilemma - "Perl software of the year". By awarding successful/impactful Perl projects, we will add visibility to Perl and it'll give incentive to people to write more software in Perl. It doesn't have to be a Perl module. It can be software written in Perl or a website with Perl backend. Unlike the grant program where we have to determine the value before delivery, we can give an award after the fact without risk.
The prize depends on the TPF budget, but it won't be a showstopper. Its initial monetary value could be as small as the White Camel award.
Request for your comments!
P.S. I am not trying to alter the existing grant program, which has its own value.
(P.S. I see some people can't comment at blogs.perl.org. If you have an issue, feel free to email to me so I can publish your comments here)
Peter Rabbitson sent me this idea:
I can not think of anything qualifying as doesn't have to be a huge Perl project* However, I have an idea which unquestionably will benefit the Perl community immensely, yet has a remarkably low barrier to entry (mainly one thing - patience). I propose that someone applies for a grant in the role of DBIx::Class re-documentation project lead.
I have had inklings of "there got to be a better way to do things", but it wasn't until I read this meditation by BrowserUK that it dawned at me: Fixing up the better-than-most-but-still-terrible documentation of DBIC is a ~200 person-hour undertaking, which on top of that requires someones fresh eye. Given that DBIx::Class is a "staple-module" in the contemporary Perl ecosystem, I believe it is reasonable to expect for the TPF to "pick up the tab" if someone with the right qualifications steps up.
So what is wrong with DBIC's documentation anyway?
- Lack of entry level architectural documentation steering a beginner towards most effective use of this library
- It is not clear DBIC is not exclusively an ORM
- It is not clear what is the primary problem it is intended to solve
- Lack of a consistent overarching approach to the subject - the current docs are riddled with localized fixups, completely ignoring the "larger picture". As examples consider:
- or perhaps https://rt.cpan.org/Ticket/Display.html?id=83767#txn-1188058
- Lack of documentation clearly delineating the components, and extension points
- Lack of clarity what is and what isn't safely overrideable
- Too many "learn by doing" tutorials, unaligned and sometimes even conflicting with each other
- Lack of proper versioning markers in the reference documentation (X available since version such and such)
- Lack of consistent documentation of method signatures
- Inconsistent/incomplete exception texts: Ideally a DBIx/Class/Diag.pod modeled on 'perldoc perldiag' as a central exception text repository (though note - categorically no exception objects)
- Worst part - a number of other problems that I am completely unaware of, as I know the source code inside-and-out, and can only notice the "disconnect" based on questions being repeatedly asked on IRC So what would the ideal candidate for the job would look like?
- You have general familiarity with Perl conventions and "perlish documentation practices" You have decent understanding of SQL, ideally being able to follow this presentation in its entirety
- You are able to dedicate large contiguous blocks of time to the project
- You are not afraid to ask followup questions and followups to the followups, until you have a solid understanding of the thing you are actually trying to document.
- You have little experience with DBIx::Class - this is not a typo: the cleaner your slate is when starting, the better you will be able to grasp the very essence of this library and be able to present in a language accessible by those who will be consuming your work in the future. I believe the work needs to at least be able to capture things like:
- DBIC is decidedly not a classic ORM
- DBIx::Class::Core is an under-designed reference implementation
- DBIC in no way mandates a properly designed schema
- You are patient
- It is of paramount importance to ensure that the documentation does not become worse than it is now. This will likely involve multiple iterations to ensure code and documentation agree (in case of disagreement code always wins, but the goal is to eliminate all such mismatches in the first place)
- Moreover it is quite likely that your work will not show up on CPAN several months (up to a year) after the grant is successfully completed. The library is the bedrock of hundreds of businesses worldwide, hence the current architect is extremely conservative in both matters of code and docs. What will the project provide to a successful/approved applicant?
- Authority to demand full and timely answers to any questions you they have arising from the current documentation, code, or comments.
- Unlimited access to a person with complete (as in "familiar with every single line") knowledge of the codebase. What else is missing?
- Probably a grant manager - while being versed in all things perl5, I am rather terrible at progress reports, and other bureaucracy. Besides the "unlimited access to answers" will keep me busy enough as it is.
So... any takers? Praises? Flames? :)))
Cheers Peter "ribasushi" Rabbitson Principal DBIx::Class cat herder
* In fact I strongly believe that work taking "a few weekends" can not possibly benefit the community, and framing the requests this way actively hurts the grants but that's a whole another topic.
Alex aka ASB gave me this proposal:
We (the Perl community) currently do not have a CPAN module that handles OData (cf. odata.org). There seems tob e an attempt to do it here: OData::Client But it's not finished yet, and i fit doesn't get a care taker, it will never be done. Also, there is client and server parts. Let's get both :)
Side node: Eventually, I'm too dumb to see that we don't need one because Perl can do it out oft he box. But if this ist he case, eventuelly, it would be a good idea to put up a grant to create a document describing how to use OData with Perl (like this one)
Search this blog
- September grant round started
- RFC: Perl software of the year award
- Grant idea - DBIx::Class re-documentation
- Grant idea - OData
- Grants for applications (vs. Perl infrastructure)?
- Grant idea - pack and unpack on streams
- Grant ideas
- RFC: Limiting grant duration
- Grants Committee 2014