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.

のようにプラグイン名を含みます。それは非常に役に立ちます。

---

更新履歴

• 2006/05/26 : コミッターガイドラインへのリンク追加
• 2006/05/26 : IRCチャンネルにfreenode追加
• 2006/05/25 : 「出来ればコミットする前にたずねてください」を追加