OpenPNE開発のガイドライン

本WikiにはOpenPNE開発のガイドラインに関する、概要説明や仕様などの確定した情報を記載 しています。

開発版リリースガイドライン

  • βはメジャーバージョンアップの1ヶ月前までにリリースする
  • βは機能追加FIX
  • 最終RCはメジャーバージョンアップの1週間前までにリリースする
  • 最終RCは既存の報告されているmajor以上のdefectチケットをすべてcloseしたものをリリースする
  • beta版以前はpatchを作成しない

安定版リリースガイドライン

リリーススケジュール

  • 原則として、月一リリースとする
  • リリース日は第3水曜日(仮)
  • 緊急のバグが見つかった場合は、上記日程に関係なく緊急リリースをおこなう

機能追加条件

  • リリース2週間前までに開発版としてリリースされている(コミットだけではダメ)
  • DB構造変更の必要がない
  • 安定動作に支障がないと判断されたもの

メンテナンス期間

http://sc.pne.jp/cmd/200801082334.png

メンテナンス期間は2つ先の安定版のbetaリリースまで(例:2.6系のメンテナンス期間は、2.10beta1のリリースまで)


チケット作成ガイドライン

チケット作成ショートカット

OpenPNE2

要望 不具合
要望チケット作成 バグ報告チケット作成

OpenPNE3

要望(core) 不具合(core) 要望(plugins) 不具合(plugins)
チケット作成 チケット作成 チケット作成 チケット作成

フォーム記入内容

チケットは以下のような設定で作成する。

OpenPNE2

フォーム名 要望リクエスト バグ報告 バグ修正
(バグ報告が確認され次第、修正に変更される)
Your email or username ログイン名が入るため、変更しない ログイン名が入るため、変更しない ログイン名が入るため、変更しない
Short summary 要望の要約 発生した現象の要約 修正する不具合の要約
Type enhancement defect defect (安定版で発生するが開発版でのみ修正するバグの場合、 enhancement)
Full description フォーマットに沿って要望の内容を記述する。 フォーマットに沿って要望の内容を記述する。 フォーマットに沿って要望の内容を記述する。
Priority 変更しない(minor)。
仕様策定・実装の段階で変更
変更しない(minor)。
現象確認の段階で変更
バグの緊急度にあわせる
Component 内容に合うcomponentを選択 内容に合うcomponentを選択 内容に合うcomponentを選択
Keywords 「(開発版バージョン)要望」と入れる
(現在は「2.13要望」)
「再現待ち」と記入 安定版対応の場合、同時に対応する旧安定版のバージョン
Cc 空欄 空欄 空欄
Milestone 空欄 選択しない 対応するバージョン
Version 空欄 同じ現象が発生し得るバージョン 同じ現象が発生するバージョン
Assign to 空欄 空欄 空欄

OpenPNE3

フォーム名 要望 バグ
Your email or username ログイン名が入るため、変更しない ログイン名が入るため、変更しない
Short summary 要望の要約 発生した現象の要約
Type enhancement defect
Full description 要望の内容を具体的に記入する 不具合の内容を具体的に記入する
Priority 変更しない(minor)。
仕様策定・実装の段階で変更
変更しない(minor)。
現象確認の段階で変更
Component core / plugins のいずれか core / plugins のいずれか
Keywords 既存のpluginsの場合はプラグイン名 plugins の場合はプラグイン名 
Cc 空欄 空欄
Milestone 選択しない 選択しない
Version 対応するバージョン 発生するバージョン
Assign to 空欄 空欄

Descriptionフォーマット

チケットのdescriptionは以下のフォーマットにあわせる

【要望リクエスト】

=== ■概要 ===
ここに要望の概要を記入

=== ■仕様 ===
仕様がある場合、仕様を記入
(決まっていなければ=== ■仕様 ===のみでかまわない)

=== ■関連情報 ===
報告元へのリンク・仕様書・関連するチケットなどの補足情報を記入

【バグ報告】(再現確認がおこなわれていないバグの報告に用いる)

=== ■現象 ===
発生した現象を記入

=== ■発生バージョン ===
バグが発生したバージョンを記入

=== ■再現手順 ===
バグを再現するための手順を記入
(手順をかきようがない場合は空欄でかまわない)

=== ■環境 ===
バグが発生した環境を記入
 * OS
 * ブラウザ
 * 携帯キャリア・機種
 * サーバ環境
など

=== ■関連情報 ===
報告元へのリンク・関連するチケットなどの補足情報を記入

【バグ修正】(再現確認がおこなわれた後の defect チケットに用いる)

=== ■現象 ===
発生した現象を記入

=== ■原因 ===
バグが発生した原因を記入

=== ■修正内容 ===
修正内容を記入

=== ■関連情報 ===
報告元へのリンク・関連するチケットなどの補足情報を記入

重複確認

要望リクエスト・バグ報告をする前に既存のチケットを確認して、重複を出来るだけ避けること。

  要望リクエスト バグ報告 バグ修正
チケット一覧 要望チケット一覧
2.11開発開始時から寄せられた要望一覧
再現待ちチケット一覧 2.8.xチケット一覧
2.10.xチケット一覧
2.11.xチケット一覧

Type選択基準

【defect】(不具合)
不具合(ただし、安定版でも発生するが開発版でしか修正しないものはenhancementとする)
【enhancement】(拡張)
開発版のみで対応する改善、 または要望。
【task】(タスク)
enhancement・defectチケット対応に関連する作業、 またはdefectにもenhancementにも属さない作業

【taskの使用例】enhancementチケット対応に関連する作業

  • #1711 au携帯のメール投稿絵文字投稿機能を追加(enhancement)
    • 関連チケット:#1534 AU携帯絵文字投稿機能対応コードの取り込み(task)

priority基準

blocker 緊急リリースが必要
critical 次回リリースで必ず対応(見送り不可能)
major 次回リリースで対応予定(見送り可能)
minor 対応未定
trivial 把握しておく

version選択基準

versionはバグの発生しているバージョンの確認に使用する

【バグ報告時】
そのバグが発生し得る全てのバージョンを入れる。 (バグが発生した機能が入っている全てのバージョン)
【バグ確認後】
そのバグが発生している全てのバージョンを入れる。 対応する場合はversionに入っている全てのバージョンを修正する。
【enhancement】
開発版でのみ対応するバグの場合、versionを指定する。 機能追加など、バグ以外の場合はversionは使用しない。

Component選択基準

component 対応プロジェクト 説明
pne-admin 管理画面プロジェクト 管理画面に関わる内容に使用
pne-api API開発プロジェクト API開発に関わる内容に使用
pne-biz PNEBIZプロジェクト PNEBIZ機能に関わる内容に使用
pne-kansai PNE関西 PNE関西に関わる内容に使用
pne-ktai PNEKtaiプロジェクト 携帯版の全般に関わる内容に使用
pne-masterslave MasterSlavePNE MasterPNE,SlavePNEに関わる内容に使用
pne-opensocial OpenSocial情報 OpenPNEのOpenSocial化に関わる内容に使用
pne-postgresql PostgreSQLプロジェクト OpenPNEのPostgreSQL対応に関わる内容に使用
pne-website OpenPNEWEBサイト OpenPNE関連サイトに関わる内容に使用
pne-xhtmlcss XHTML+CSS OpenPNEのXHTML+CSS化に関わる内容に使用
その他 - 上記のコンポーネントに該当しない内容に使用

Milestone選択基準

Milestoneは対応が決定したチケットにのみ使用する。

複数のバージョンで対応する場合は、一番優先度の高いものをMilestoneとする。
その場合、Miletsoneには入っていないが対応するバージョンをKeywordsに記載する。

Milestoneの優先度安定版>旧安定版>開発版

プロジェクトチケット作成ガイドライン

http://sc.pne.jp/200801082326.png

この図のように

  • type = projectとする
  • summary の先頭に【プロジェクト名】と入れる

上記2つをプロジェクト用のチケット作成時のガイドラインとする。

また同一プロジェクト内の作業(タスク)については、

  • type = task or enhancement
  • summary の先頭に【プロジェクト名】と入れる

とする。

プロジェクトチケットの表示

個別のWikiページにプロジェクトチケットを表示する場合には

== プロジェクトチケット ==
[/newticket?summary=%E3%80%90%E7%8E%84%E7%AE%B1PNE%E3%80%91&owner=junchiba 簡単チケット作成(summary=【玄箱PNE】&owner=junchiba)]

=== @in-BOX ===
[[TicketQuery(summary~=【玄箱PNE】&status=new&resolution=|&priority!=trivial)]]

=== @次の行動 ===
[[TicketQuery(summary~=【玄箱PNE】&status=assigned&resolution=|&priority!=trivial&type!=project)]]

=== @プロジェクト ===
[[TicketQuery(summary~=【玄箱PNE】&status=assigned&resolution=|&priority!=trivial&type=project)]]

=== @いつかどこかで ===
[[TicketQuery(summary~=【玄箱PNE】&resolution=|&priority=trivial)]]

[[WikiInclude(DIRECTORYNAVI)]]

上記の用にする。summary~=【玄箱PNE】とすることで、プロジェクトチケットを取得できる。

チケット状態ガイドライン

チケットに設定されるKeywordの解説とその遷移図を確認し、 そのチケットの状態と次に行うべき作業を確認する。

バグチケット

【再現待ち】
バグ再現を行い、報告された現象が実際に起こるかどうかを確認する⇒再現できた場合は【Keywordなし】へ、出来なかった場合は【再現せず】へ
【Keywordなし】
再現が確認された状態(Keywordは空欄となっている)。バグ修正を行う⇒【確認中】へ
【確認中】
修正が終わった状態。コードチェックを行い、問題がないか確認する⇒問題がなかった場合は【テスト待ち】へ、問題があった場合は【差し戻し】へ
【テスト待ち】
修正・コードチェックが終わった状態。動作テストを行い、問題がないか確認する⇒問題がなかった場合は【fixed】へ、問題があった場合は【差し戻し】へ
【再現せず】
再現が確認できなかった状態
【差し戻し】
コードチェック・動作テストで問題があった状態。再び修正を行う
【fixed】
動作テストが終わって問題が無ければKeywordを削除してチケットを閉じる

チケット編集ガイドライン

クローズ

チケットをクローズする場合は、必ず自分にreassignをかけてから行うこと。
クローズの種類は以下の基準に合わせて選択する。

【fixed】
既に対応が完了しているチケットに使用。この場合のみ、自分ではなくチケットのタスクを行ったユーザにassignをかける
【invalid】
無効のチケット(誤って作成したチケットなど)に使用
【duplicate】
他のチケットと内容が重複したチケットに使用。この場合、コメントに重複したチケットのIDを記載すること
【wontfix】
対応しないチケットに使用。通常は使用しない
【worksforme】
報告されたバグを再現できなかった場合に使用

収集ガイドライン

定期的にOpenPNE公式SNS内の書き込みを確認してバグ・要望を収集する。
収集の流れはpne-member参照。

バグ収集

  • バグ収集は日記、トピック、トピックコメントを確認する
  • 不具合報告の書き込みを発見したばあい、再現待ちのdefectチケットを作成する
  • チケットのフォームは基準に合わせるが、descriptionは報告元のURLと内容のみにする
  • チケットを作成したら、報告元の記事に必ずチケットのURLをコメントする

要望収集

  • 要望収集は日記のタイトルに【要望】と入っている記事のみ確認する
  • 要望報告の書き込みを発見したばあい、enhancementチケットを作成する
  • チケットのフォームは基準に合わせるが、descriptionは報告元のURLと内容のみにする
  • チケットを作成したら、報告元の記事に必ずチケットのURLをコメントする

バグ修正ガイドライン

修正バージョン

ticketのversionに入っている全てのバージョンを修正すること

コミット先

仕様書作成時のガイドライン

全て#2182のような形に合わせる

ファイル

ファイル名
日付_【次の安定版メジャーバージョン】機能要約(例:[20080403_【2.12】ファイルアップロードの拡張.ppt])
ファイルの中身
  • 必ずチケットのURLを記載する
  • 必ず作成者の名前またはメールアドレスを記載する(pptの場合は表紙に入れるとわかりやすい)
仕様書作成時サンプル画像1

コミット

コミットするときは
  • 毎回必ずコメントにチケット番号(#2182など)を入れる(例:r6306
  • コミット先 OpenPNE_specification/trunk/バージョン/spec/
コミット後
チケットのdescriptionの「■仕様」欄(要望チケットのフォーマット参照)に必ず画面仕様へのルートを入れる。(例:source:OpenPNE_specification/trunk/2.12/spec/20080403_【2.12】ファイルアップロードの拡張.ppt

ドキュメント関係のレポジトリ

 OpenPNEspecifiction - branches - 個人ごとのディレクトリ(ebihara,kunitadaなど)
                     - patch(パッチ格納場所)
                     - release(空)
                     - tag(空)
                     - trunk    - 2.12   - doc(その他調べもの・ドキュメントなどのおき場所)
                                         - spec(仕様のおき場所)
                                         - test(テスト表のおき場所)
                                - 2.10
                                - 2.8
                                - ...
                                - stock(盛り込み予定のないもの)  - doc
                                                                   - spec
                                                                   - test

要望盛り込みガイドライン

pne-guidelines-note#要望取り込みガイドライン

動作テストガイドライン

  • 動作テストはテスト表を作成して行う(Googleスプレッドシートを使用)
  • 動作テストはチケット単位でテストする
  • typeがdefect・enhancementのチケットのみテストする
  • PC版推奨機種の全てのブラウザで、できるだけ最低に近いバージョンでもテストする
  • PHPはできるだけ最低に近い推奨バージョンでもテストする
  • データベースサーバはできるだけ最低に近い推奨バージョンでもテストする

defectチケットのテスト

  • Ticketのversionに記載されている全てのバージョンのSNSでテストする
  • 以下のことに注意してテストする
    • 報告されたバグがdescriptionの「修正内容」の通りに修正されているか
    • 修正した機能の不具合の発生していなかった部分に影響がないか
    • 報告されたバグと似たような動作をする機能にバグが残っていないか
    • 報告されたバグに関連する機能にバグが残っていないか

enhancementのテスト

  • 以下のことに注意してテストする
    • 仕様どおりに動作しているか
    • (仕様書がない場合)UIデザインがOpenPNEの中で異質なものになっていないか
    • (仕様書がない場合)動作がOpenPNEの中で異質なものになっていないか
    • (仕様書がない場合)不足している動作・機能がないか
    • 例外的な動作に対して対応できるか
      • 必須項目が空欄
      • 存在しないIDが指定される など

テスト中に不具合を発見した

  • 現象の内容
  • 発生環境(SNSのバージョンなど)
  • 再現手順

などをコメントに入れてテスト中のチケットを差し戻す。

テストが完了した

チケットをfixedで閉じる。

機能追加ガイドライン

http://sc.pne.jp/200802170035.png

OpenPNEプロジェクトでは、OpenPNEを進化させるためのソースコードの提供を歓迎します。 UIに関わるパッチかそうでないかによって受け入れ手順が変わります。

UI変更を伴わない不具合修正・機能追加

UIに影響の無い不具合修正や機能追加は、パッチを送付頂ければOpenPNEの開発版ソースコードにマージします。

UI変更を伴う機能追加

OpenPNEのUIに変更を与えるような機能追加の場合は、UIの整合性を統一する作業が必要になります。 UI検証チームによって整合性を評価し、仕様の追加変更作業を行います。



Attachments