CommitterGuideLines日本語訳
Plaggerのコミッターガイドラインが公開されましたが、英語が弱い自分は理解出来てるかが不明です。そこで、勝手に日本語訳を公開して、間違いを指摘してもらおうと思います。
指摘があれば随時変更しますので宜しくお願いします。
どうしたらPlaggerコミッターになれますか
もしあなたがプラグインに対する良いアイデアやパッチがあれば、以下の方法があります。
- Email the development mailing list
- #plagger(英語)か#plagger-ja(日本語)のIRCチャンネル(freenode)接続(お勧めです)
- あなたのBlogにエントリーを作成し、"plagger"タグでdel.icio.usへ
もしあなたのプラグインがすばらしく見えるか、継続してPlaggerの開発に貢献できるように思える場合はsubversionへのコミット権を差し上げます。htpasswd -nd youraccountの結果を私へEmailで送信してください。svnのアカウントではTracへログインし、Ticketのcreate/assignとWikiの変更が出来ます。
なぜSVNにコミットするのですか？
現在プラグインのAPIは流動的で、1.0がリリースされるまではまだ変更があるでしょう。そのため、ユーザーが混乱しないように私たちのコントロールの下に置くことを勧めます。もしプラグインのAPIを変更する場合は、私(miyagawa)はsvnにあるプラグインに配慮します。
APIが固定されたら、あなたは作成したプラグインをCPANで公開することが出来るでしょう(CPANはPerlモジュールを配信するのに適しています)。
コミッターとして順守すること
コアモジュールを変更しないでください
リリース作業の為、コミット権があってもPlaggerのコアモジュールへの直接の変更を行なわないでください。直接変更を行なう代わりに、パッチを作りURLを連絡してください(それかリストをEmailで送信)。
パッチに問題がなさそうであれば、適用してコミットします。これは、ロードマップに向けての作業と、将来的な copyright/licensing の管理において、非常に重要な点です。
どれがコアモジュールに指定されているかは、PlaggerCoreModulesを参照してください。
出来ればコミットする前にたずねてください
私たちのsvnコミット権はいつでもどんな変更もできますが、実際には行なわないでください。
- 新しいプラグインを作成しコミットする時には、IRCチャンネルへレビューを依頼してください。
- 既存のプラグインを強化する場合には、最初にレビューを依頼してください。
- 明白なバグ(コアモジュールを除く)は直接変更してください。その際にはTracのチケットを開くことを推奨します。
- 既存プラグイン(EntryFullText,TruePermalinkやFindEnclosures)の*.plや*.yaml等のメタプラグイン(assets)は直接変更してください。
もしあなたに所有権があるブランチがあれば、リーダーシップを持って開発を加速させるとともに、直接新しいファイルをコミットできます。詳細に関してはPlaggerBranchesを見てください。
プラグインをコミットするとあなたのコードは全ての人に所有されます
あなたがPlaggerのsvnへコミットすると、あなたのコードは全てのPlaggerの開発者の所有物となります。もちろんあなたは自分で書いたコードに著作権を持っていますが、必要があればいつでも他のコミッター(特に私)が、あなたのコードをアップデートするでしょう。プラグインを変更する場合は 1)プラグインAPIを変更した時 2)他のプラグインが機能を追加した時 に時々起こります。
もしあなたが他人から変更されることを望まないときは、コミットせずに自分自身で管理してください。その場合は、私たちがAPI等を変更した時に自分自身でプラグインをアップデートしなくてはなりません。
あなたのコードはPerlと同じライセンスになります
この文章を書いている現時点で、PlaggerはPerlと同じライセンスです。
Except where otherwise noted, Plagger is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
もしあなたが、プラグインで他のライセンスを主張していなければPerlと同じライセンスと思われます。
したがって、たとえばGPLのライブラリからコードを流用しないでください。流用するとあなたのプラグインのライセンスはGPLとなります。私がライセンス問題の被害を受けない為に、私たちはPerl(Artistic/GPL)やMIT、BSDライセンスのみを許可します。
プラグインはシンプルにしてください
プラグインは出来るだけ簡単にしてください。コードと設定は少ないほうがいいです。実際に、Plaggerのプラグインで最も良いのは
- module: Something::Blahblahだけで、config:が全く無い設定です。
また、ひとつのプラグインで複数のことをしないでください。Plaggerは非常に有名なUnix哲学のWrite programs that do one thing and do it well.に基づいて作成されていますので、プラグインを書く際もそれと同様にしてください。
ドキュメントを用意してください
POD部分にあなたのプラグインの説明を書いてください。SYNOPSISにはコピー＆ペーストで実行できる設定の例を含むべきです。もし、必要であれば required/optional の設定も同様に。重ねて言いますが、設定無しが最善です。説明を書く手間も軽減できますし:-)。
Testsを用意してください
私たちは、0.7.xリリース以降コアモジュールと退化したバグ、プラグインの為に、テストスイートを書き始めました。trunk/plagger/t/pluginsにあるテストスイートを見て、あなたのプラグインのTestsを書き始めてください。それらのTestsは開発にのみ有効で、モジュール依存に対処しなくても良いようにCPANには登録しません。
コミットするときはわかり易いログを書いてください
PlaggerChangelogに要点を記述する際に、私は前回のリリースからの変更点をsvnログから探します。あなたはわかり易いコミットログを提供してください。たとえば以下のようなログ
bug fix.は全く役に立たないので避けるべきです。最善のコミットログは、
Filter::TruePermalink: Fixed bugs in youtube.yaml to avoid infinite loops.のようにプラグイン名を含みます。それは非常に役に立ちます。
更新履歴
