Makoto Nozaki

We have five proposals to review, including the one from July.

http://news.perlfoundation.org/2015/09/september-2015-grant-proposals-1.html

This is a Japanese summary of Grants Committee Charter, How to write a proposal and Grant Benefits.

YAPC::Asiaが目の前に迫ってきました。日本のPerl使いの皆様向けにThe Perl Foundation内のGrants Committeeの活動を紹介します。

以前Grants Committee委員の牧から案内がありましたように、Grants CommitteeはPerlの開発に貢献する個人に1万ドルを上限として助成金の交付を行っています。もちろん日本の皆さんも対象で、最近はmoznion氏のPerl::Lintが採択されました。以下に私たちの活動理念と助成金の応募方法を記します。少し長いですがどうぞお付き合いを。

Grants Committeeの紹介

Grants Committeeは米国非営利法人、Perl Foundation内の最大勢力を占める委員会です。

Grantは日本語に翻訳しにくいのですが、助成金委員会とでも申しましょうか。オープンソースの活動は個人が自分の時間を使って無報酬で行われることが多いものの、人間は霞を食べて生きるわけにはいかないため、Perlのプロジェクトを通してPerlの成長に貢献してくださる方にGrants Committeeが助成金を出しています。

委員長は私、野崎が務めています。委員はコミュニティの代表を世界各地から集める方針を取っており、アジア・太平洋地域からは牧大輔とKaren Pauleyが選出されています。その他北米4人、欧州の4人の委員に加え、アジア・北米・欧州からGrant Managerという役職に1名ずつついており計14人の所帯です。

助成金の申請から採択、支払いまで

流れはこのようになっています。

• 提案の送付（フォーム）。このようなプロジェクトををするのでこれだけの助成をされたい、という内容を送っていただきます。メールアドレスなど個人情報を除き、内容は公開されます。
• 奇数月の中旬にパブリックコメントを募集し、委員による投票が行われます。
• 賛成多数で採択。提案に沿って実行していただきます。なお月一度の進捗報告が求められます。
• 計画達成後、現金が支払われます。

参加する利点

採択されると助成金に加えてこのような利点があります。

• 専属マネージャーが割り当てられ、進捗管理とTPF間の仲介をしてくれます。
• TPFお墨付きのプロジェクトになり、世界中から注目が得られます。

FAQ的なもの

英語は必要か？

英作文が必要になるのは以下の場合です。

• 提案の作成、質問への返答
• 進捗報告
• 支払い手続きなど事務的なやりとり

READMEを書く手間プラスαくらいでしょうか。牧によると「英語が問題ならば多少のお手伝いはできます」そうですよ！

申請額はどうやって決めたらよい？

上限が1万米ドルという以外、特にガイドラインは設けていません。過去の申請額を参考にするのがよいかと思います。なお2014年2月までは上限が3000ドルでした。

寄付金で成り立っているプログラムのため、時給換算ではさほど多くの額は望んでいただけないことをご承知ください。

支払いは？

計画達成後、委員会が確認したあとに米ドル建ての小切手が郵送されます。小切手はシティバンク銀行などで換金できます。銀行振り込みもできないことはないのですが、国際送金手数料の負担をお願いしています。

ちなみに円安の今がチャンスです。

財源は？

TPFに寄付をしてくださった皆様のおかげです。末筆ながらTPFに寄付をしてくださった法人・個人の皆様に感謝いたします。

お問い合わせ

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:
  • https://github.com/dbsrgits/dbix-class/pull/21#issuecomment-15849436
  • https://rt.cpan.org/Ticket/Display.html?id=63843#txn-867585
  • 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)