Mahara日本語ドキュメント/開発者エリア/バグステータス

作成中です - mits (talk)

Launchpadのステータス、優先度、マイルストーンおよびタグは効果的なバグ管理のためMaharaコアチームにより使用されています。このページではこれらの機能の現在の利用に関して説明します。

ステータス　Status

バグステータスはバグの現在の状態を反映しています。新しいバグが報告された場合、(特に指定がない限り) 自動的に「New (新規)」ステータスになり、 その後、開発者の行動および決定により、通常いくつかのステータスを経ます。以下のリストではそれぞれのステータス説明およびステータス変更に関する有用なヒントを提供します。

• New - The status field is automatically set to "new" when a bug is created.
• New (新規) - バグが作成された時点でステータスフィールドには自動的に「New」が設定されます。
• Triaged - Once we've looked at a bug and decided on a priority and a milestone, it's changed to "triaged". Triaged is for bugs we haven't tried to reproduce.
• Triaged (トリアージ) - 私たちがバグを確認して優先順位およびマイルストーンを決定した場合、そのバグは「Triaged (トリアージ)」に変更されます。トリアージされたバグとは私たちがまだ再現を試みていないバグのことです。
• Confirmed/Incomplete - Status is changed to "confirmed" once we've been able to reproduce it or to "incomplete" if we need more information to be able to reproduce it.
• Confirmed (確認済み)/Incomplete (未完了) - ステータスは再現できる場合は「confirmed (確認済み)」、再現するためにさらに情報が必要であれば「incomplete (未完了)」に変更されます。
• Invalid , Wont fix, Opinion - These are statuses that effectively close the bug.  "Invalid" is for things we don't really think are bugs at all, or maybe they're bugs but not bugs in Mahara. "Won't fix" is self-explanatory. "Opinion" is a softer version of "won't fix" and indicates to the reporter that there is reasonable disagreement about whether the bug is a bug or should be fixed (and invites more comments).
• 無効, 修正予定なし, 意見 - これらは事実上バグをクローズするためのステータスです。「無効」は私たちが本当にバグだと思っていないもの、あるいはバグかもしれないがMaharaのバグではないものです。「修正予定なし」は文字通りです。"Opinion" is a softer version of "won't fix" and indicates to the reporter that there is reasonable disagreement about whether the bug is a bug or should be fixed (and invites more comments). 「意見」は「修正予定なし」の柔らかいバージョンであり、バグがバグであるか修正されるべきかについて妥当な意見の相違があることを報告者に示します (そして、より多くのコメントを勧めます)。
• In progress - The bug is currently being worked on.
• 進行中 - バグは現在対応中です。
• Fix committed - A fix is committed to git. Bugs which have been fixed only in the commit author's local branch or personal clone repository, or submitted for revision should not be marked as "Fix Committed" until they appear in the master (or stable) branch from which releases are created (which will happen when the change on the revision system is marked as merged).  Any time a bug is marked as "fix committed", the milestone field must also be updated to the next planned release milestone on the appropriate branch, and if the bug is still unassigned, it should be assigned to whoever provided the patch.
• 修正内容コミット済み - 修正内容がgitにコミットされています。Bugs which have been fixed only in the commit author's local branch or personal clone repository, or submitted for revision should not be marked as "Fix Committed" until they appear in the master (or stable) branch from which releases are created (which will happen when the change on the revision system is marked as merged). コミット作成者のローカルブランチまたはパーソナルクローンリポジトリまたはsubmitted for revisionでのみ修正されたバグはリリースが作成されるmaster (または安定版) ブランチに現れるまで「修正内容コミット済み (Fix Committed)」とマークすべきではありません (これはthe revision systemの変更がマージされたとマークされた場合に発生します)。  Any time a bug is marked as "fix committed", the milestone field must also be updated to the next planned release milestone on the appropriate branch, and if the bug is still unassigned, it should be assigned to whoever provided the patch.バグが「修正内容コミット済み」とマークされた場合、マイルストーンのフィールドも適切なブランチの次のリリース予定マイルストーンに更新する必要があります。また、バグがまだ割り当てられていない場合、パッチを提供した人に割り当てなければなりません。
• Fix Released - Status is flipped to "Fix Released" once there is a stable release (i.e. a tarball), which includes the fix (alphas, betas and release candidates don't count).
• 修正リリース - ステータスは修正を含むステイブルリリース (例 tarball) が公開された時点で「修正リリース」に切り替わります (アルファ版、ベータ版、リリース候補版はカウントされません)。

Periodically, the core development team will go through the open bugs, decide what should be fixed before the next release and update the status and milestone fields accordingly. 定期的にコア開発チームは未解決のバグに目を通して、次のリリースまでに何を修正すべきか決定します。それに応じてステータスおよびマイルストーンのフィールドを更新します。

重要度　Importance

Importance is highly subjective, but here are some rough guidelines for how we use them in Mahara. A bug with the following importance might have some of these characteristics: 重要度は非常に主観的なものですが、Maharaにおける重要度の大まかなガイドラインを以下に示します。以下の重要度を持つバグにはいくつかの特徴があります:

• Critical: Use only when we should drop everything and fix this ASAP
• クリティカル: すべての作業を止めて早急に解決すべき場合にのみ使用します。
  • Prevents Mahara from functioning entirely
  • Maharaの機能を完全に停止させてしまう。
  • Causes data loss or other irreversible problems
  • データ損失やその他の不可逆的な問題を引き起こす。
  • Likely to be encountered by many users
  • 多くのユーザーが遭遇する可能性が高い。
  • Security flaw that doesn't require any user account on the site
  • サイトのユーザアカウントを必要としないセキュリティ上の欠陥。
  • Something that must get done before the next release
  • 次のリリースまでに必ずやらなければならないこと。

• High
• 高
  • Obviously "broken" to end user. Visible error messages, wrong item being deleted, etc.
  • エンドユーザにとって明らかに「壊れている」状態です。目視確認可能なエラーメッセージ表示、間違ったアイテム削除等。
  • Likely to be encountered by many users
  • 多くのユーザが遭遇する可能性が高い。
  • Security flaw that requires a logged-in user account on the site
  • サイトにログインしたユーザアカウントを必要とするセキュリティ上の欠陥。
  • Usability problem that causes extreme inconvenience
  • 極めて不便を強いるユーザビリティの問題。

• Medium
• 中
  • Incorrect behavior, but a workaround is possible
  • 不正な動作であるが、回避可能な状態。
  • Unlikely to be encountered by most users
  • ほとんどのユーザは遭遇する可能性が低い。
  • Security flaw that requires an admin account and/or has limited consequences
  • 管理者アカウントを必要とする、または限定的な結果をもたらすセキュリティ上の欠陥。
  • Usability problem that causes major inconvenience
  • 大きな不便をもたらすユーザビリティの問題。

• Low
• 低
  • Works correctly, but doesn't follow best practices
  • 正しく動作するが、ベストプラクティスに従っていない。
  • Affects very few users
  • 極少数の人に影響する。
  • Easy workaround is available
  • 簡単な回避策あり。
  • A minor deviation from security "best practices", but not close to exploitable by itself
  • セキュリティの「ベストプラクティス」から僅かに逸脱しているが、それだけでは悪用可能なレベルではない。
  • Usability problem that causes moderate or minor inconvenience
  • 中程度または軽度の不便をもたらすユーザビリティ上の問題。

• Wishlist
• ウィッシュリスト
  • Not a bug
  • バグではない。
  • Suggestions for new features & functionality
  • 新機能の提案。

タグ　Tags

We encourage the use of tags to group bugs together! Some recommended tags: バグをグループ化するためのタグの使用を推奨します! 以下、おすすめのタグです:

• bite-sized: A bug with a trivial fix. We use these during training to introduce new developers to Mahara's development process.
• ひとくちサイズ: 些細な修正を伴うバグです。私たちは新しい開発者にMaharaの開発プロセスを紹介するためのトレーニングにこれらを使用します。

• snack-sized: A bug that is slightly harder than bite-sized. We use these during more advanced Mahara development training events.
• スナックサイズ: 一口サイズより少し難しいバグです。より高度なMahara開発トレーニングイベントで使用します。

• ie9, ie10, ff, chrome, opera, safari, etc.: A tag that indicates a browser-specific bug.
• ie9, ie10, ff, chrome, opera, safari, 等.: ブラウザ固有のバグを指定するためのタグです。

• front-end: A bug that requires a front-end developer, i.e. for CSS, HTML and Javascript changes.
• front-end: CSS、HTML、Javascriptの変更等、フロントエンド開発者を必要とするバグです。

• mysql, postgres: A bug that only affects one type of database.
• mysql, postgres: 1種類のデータベースのみに影響するバグです。

• fastcgi, nginx, windows: A bug that's only present when running Mahara in a non-standard environment.
• fastcgi, nginx, windows: Maharaを非標準環境で動作させた場合にのみ発生するバグです。

• usability: Indicates a problem area in Mahara's user interface; i.e. things that are difficult for users to figure out, or tasks that are annoying or difficult to accomplish.
• usability: Maharaのユーザインターフェースにおける問題領域を示します: 例)ユーザの理解が困難なもの、煩わしいもの、または達成が困難なタスク

• ldap, note, blogs, tinymce, groups, etc.: Tags that indicate which plugin or part of Mahara a bug affects.
• ldap, note, blogs, tinymce, groups等: バグがどのプラグインまたはMaharaのどの部分に影響するのかを示すタグです。

• regression:
• 後退:
  • Functionality that used to work, but stopped working after a known code change.
  • It's helpful to use git bisect to find the exact code change that introduced the bug, so that you can correct the underlying problem.

セキュリティ　Security

Bugs with security implications should be marked as Private Security in the This report contains information that is... option. See this page for more info: Security セキュリティに影響するバグには'This report contains information that is...オプションでPrivate Securityとマークしてください。詳細は次のページをご覧ください: [セキュリティ]]

When the bug fix for a security bug is released, its status should be changed to Public Security. Or, if a bug is already widely known, or if it's a very low-priority security bug, it may be advisable to change it to Public Security even before its release.

マイルストーンおよび「影響」 Milestone & "Affects"

影響を受けるバージョン Affected versions

The "Affects" column indicates which series' of Mahara the bug is present in. In most cases this will include the current development series. You should check to see whether the bug is also present in the current three supported releases.

マイルストーン Milestone

The milestone is used for three main things:

1. as a TODO list for an upcoming release
2. as a record of when a bug was fixed
3. as an extended changelog for a given release

You can decide whether & which milestone to apply based on the bug's status:

• Triaged, Confirmed, or In Progress: Assign a milestone if:
  • We want to get it in the next possible release
  • And/or a developer has actually started implementation on it

• Fix committed: Always assign a milestone, indicating the next stable release for the branch.

• Fix released
  • Usually a bug in this status will have passed through "Fix committed" first, so it will already have a milestone.
  • Exception: Sometimes an old bug in the tracker turns out to be no longer present in the latest release because some unrelated piece of code solved the problem. In those cases, you can change the bug's status to "Fix released" but give no milestone.

• Won't fix: A bug in "Won't Fix" status should not have a milestone.

バックポーティング　Backporting

We don't backport all bug fixes to all versions of Mahara. For the full details see: "Supported Versions: Definition of support"

Here's how we record backporting decisions in Launchpad. If you know a bug is present in older Mahara release:

• Supported release, Will backport: Mark the series as "affected" and give it a Milestone.
• Supported release, Won't backport: Mark as "affected", no Milestone, status "Won't Fix". Marking it as affected and "Won't fix" lets us know we already made a backporting decision, so we don't accidentally rehash the same discussion.
• Unsupported release: These are never backported. Sometimes, for informational purposes, it can be useful to mark the most recent unsupported & non-fixed branch as affected and "Won't Fix". But it's entirely optional. Example:
  • If the current stable release is 22.10 Older supported releases are 22.04 and 21.10.
  • I find a bug that turns out to be a regression introduced in Mahara 21.04, then it will be backported to 22.10, 22.04, and 21.10 dev branches to be added to those stable releases.
  • Result: I may mark the 21.04 release as affected and "Won't Fix", to let people know at a glance that the bug goes back earlier than 21.10.

関連リンク　Relevant links

• Ubuntu's similar rules for prioritizing bugs: https://wiki.ubuntu.com/Bugs/Importance
• Ubuntuのバグの優先順位に関する同様のルール: https://wiki.ubuntu.com/Bugs/Importance