WordPress への貢献、その 1 : 開発
2009年3月13日, Naoko McCracken
以下は、2009 年 3 月 12 日に書かれた WordPress.org 公式ブログの記事、「Contributing to WordPress, Part I: Development」を訳したものです。
訳者注: 下記の貢献方法の多くでは、英語がベースとなっています。日本語でのバグ報告や機能追加リクエストをしたい方は、バグ報告と提案フォーラムをご利用ください。
数週間前の WordCamp デンバーにて、WordPress オープンソースプロジェクトに対してもっと皆さんが関わっていける機会を作ることについてのプレゼンを行いました。アイコンデザインコンテストが大成功を収めたのを見て、コード開発者以外の方にも才能やスキルを活かして WordPress に貢献してもらう方法を考えなくてはならないというのがはっきり分かりました。2.7 の公開後、どういった貢献の機会を作るのが適しているのかを私たちは考え続けていて、思いついたアイディアもいくつかあります。
この週末、多くの WordPress ユーザーやコアメンバーを含む開発者がサウスバイサウスウエスト (SxSW) イベントのためにテキサス州オースティンに集合します。Matt Mullenweg、Ryan Boren、私 (記事執筆者 Jane Wells) も参加します。この WordPress コミュニティをつなごうというスピリットのもとに、これから SxSW の期間中毎日、コミュニティへ貢献する新しい機会についての情報を書いていこうと思います。各投稿では、以下のうちの1つまたは複数のトピックをカバーしていきます。
- 開発 (当然ですね !)
- QA (品質管理)
- ドキュメンテーション
- アイディアと意見
- ユーザーエクスペリエンス
- グラフィックデザイン
- アクセシビリティ
- ユーザビリティテスト
- WordPress.tv
- コミュニティ運営
WordPress の貢献といえば多くの人が思いつくのは PHP 開発ですので、今回はここから始めてみたいと思います。
コード (= poetry 
) はアプリの主要部分です。貢献する機会の多くがここにあるのは当然といえます。Trac にはいつも、パッチが必要なチケットや、テストが必要なパッチや、正しい解決法にたどりつくために創造的な開発者のアイディアやコラボレーションを必要をしている迷宮入りした問題があふれています。
もしあなたが PHP をよくご存知なら、チケット (特に bug となっているもの。これらは優先的に解決されるべきです) を眺めて、どれかのパッチを書いてみて下さい。もっと高度なスキルをお持ちなら、さらに難易度の高いチケットのパッチを書いたり、必要ならば他の人が書いたパッチの修正をやってみてください。あまりコーディングスキルには自信がないけれど、アプリケーションのファイル構成はだいたい分かるということでしたら、has-patch タグが着いているチケットを探してそのパッチをできるだけ多くのブラウザでテストし、結果をチケットのスレッドに投稿して下さい。
もし日常の WordPress 利用中にバグを見つけた場合は、レポートして下さい。まず、Trac を見てその問題に対するチケットがすでに発行されているかどうかを確認しましょう。また、wp-testers list (メーリングリスト) のアーカイブでそのバグについての話題が出ているかどうか見てみたり、自分でメールを投げて情報を求めてみたりしましょう。こういったことをやっても成果がなかった場合は、Trac にてチケットを発行します (登録、ログインが必要です)。できる限り詳しく問題を説明し、
ドロップダウンカらメタデータを正しく選択するのを忘れないようにして下さい。メタデータの選び方についてよく分からないという場合は、以下をご覧下さい。
Severity (重大度) フィールドの扱いには注意して下さい。たいていのバグは、normal にカテゴライズされます。バグを high severity とマークしても必ずしも開発が早まるわけではありません。severity の選択が間違っていた場合、開発を遅らせる事にもなりかねません。
Priority (優先度) フィールドも通常は normal を選択し、より経験のある開発者が優先度を変更するようお任せしましょう。彼らは他に Trac 上にあるチケットの事もよく知っていますので、それらのチケットとの相対的な優先度を正しく評価する事ができるからです。
Ticket type (チケットの種類) は、もっとも間違って使われがちなフィールドです。多くの人が、本当はそうでないアチケットを defect (欠陥) としてマークしてしまいがちです。この問題を解決するため、ticket type とその使い方をご紹介します。選択肢は、defect (bug)、enhancement、feature request、Task (blessed) です。
- Defect (bug)、欠陥: 壊れている箇所があるときに使うタイプ。機能が本当は正しく使えるはずなのに (定かでないときは、Codex でチェックするか開発者用 IRC で聞いてみてください)、何かがおかしくなってしまって修正が必要な状態。
- Enhancement、機能強化: 使いにくい箇所があったり、スピードが遅すぎたりして、デザインまたはコーディング上の改善が必要と思われる状態 (ただし、大掛かりな関数や画面デザインのやり直しを必要としない)。もしある点が欠陥ではなく機能強化が必要なだけの場合、defect を選択しないで下さい。
- Feature request、追加機能要求: 大掛かりなインフラ、コード、画面デザインの変更を伴う改善の必要な箇所がある場合、enhancement ではなく feature request を選択すべきです。Trac は現在 WordPress に対する追加機能要求をするための場所ではありません。新機能の推薦には、アイディアフォーラムを引き続きご利用ください。各リリースサイクルごとに、コアメンバーがアイディアフォーラムを見て検討した機能を Trac に追加していきます。
- Task (blessed)、タスク: このチケットの種類は、コア開発チームからの承認を意味します。コアメンバーのみが選択すべきタイプで、自分のチケットを Task (blessed) にマークしたら、わるいカルマの影響に見舞われます !
バグ・ハンティングに参加しましょう ! バグ・ハンティング用 Codex ページ を最近ご覧になった事があるようでしたら、最近しばらく行われていなかった事に気づくと思います。でも、もうそんなことはありません ! 公式バグ・ハンティング (バグを見つけて修正をする競争イベント) が、また定期的に戻ってきます。第一回は近々 (もしかしたら来週) 告知されますので、その時はウィジェット関連のバグを発見、修正してみてください (でもそれまで待っている必要はありません。すでにたくさんの 2.8 マイルストーン向けオープンチケットが優しい開発者さんたちが注目してくれるのを待っています) 。
今まで通り、貢献したい開発者の方は、#wordpress-dev IRC チャンネル (irc.freenode.net) や wp-hackers list、そして Trac のチケットスレッドでお互いやコアチームのメンバーと連絡を取り合う事ができます。来週水曜日正午 (PST/太平洋標準時) から、毎週の定期的な開発者チャットもまた開始します。
コメントはまだありません