Jump to content

バグの管理/バグ報告のライフサイクル

From mediawiki.org
This page is a translated version of the page Bug management/Bug report life cycle and the translation is 44% complete.

このページでは Phabricator のバグの報告や新機能の要望などのタスクのやり方を解説します。

  • タスクが最初にこなされたとき、「オープン」というステータスが与えられます
  • When a task is actively being worked on, it can be given the In Progress status.
  • 特定のデベロッパーがタスクに取り組み始めたら、理想的にはそのデベロッパーがタスクの解決に取り組みます。
  • If an initial patch for a task has been put into the Gerrit code review tool, the project Patch-For-Review is automatically added to the task. (Gerrit/コミット メッセージの指針 を参照してください。)
  • タスクを閉じる:
    • A task is given the Resolved status when a code change that fixes the task has been merged in Gerrit. This does not mean that the fix is immediately available on a Wikimedia website as it can take up to two weeks.
    • A task is given the Declined status when the problem can not be reproduced, when missing information has not been provided, or when an acceptable workaround exists to achieve a similar outcome as requested. This status is also set when there's a consensus that implementing a particular task would be a bad idea. For example, when a task contradicts a particular project's scope or the principles of the project and fixing would be barred from approval by the project's maintainers (or product managers, if existing). Depending on the specifics, a user preference, a global configuration variable, a re-implementation, or forking the code can be alternatives to marking a task as declined.
    • A task is given the Invalid status when the task does not describe an actual wrong behavior, or when it is a change that is outside the power of the component's developers. For example, tasks proposing changes to third-party software or third-party website settings are INVALID, as well as requests contrary to legal or contractual obligations.
    • A task is given the Duplicate status when the task has been reported before and has been merged into another task, no matter if the other task has been already resolved or not.
    • Optionally the keyword Verified is set if a QA tester or the task author confirmed the merged fix in Gerrit after it had been deployed.
  • If a task was marked as Resolved and it turns out that this was incorrect, the task's status can be changed back to Open.
  • If a task is waiting for further input (e.g. from the task author or a third party like upstream) and can currently not be acted on, the Stalled status is temporarily given. The Stalled status can also be given when a task is waiting for its subtask(s) to be resolved first.

タスクの完了

Different teams complete the work on tasks differently, see Phabricator/Project management . QAと製品管理が変更を確認した後、プロジェクトワークボードの「完了」コラムに移動させ、その時点での「スプリント」を完了したとき、もしくはコードが製作時に使用可能なときにタスクのステータスを「解決済み」に変更するだけです。 他の人は、タスクを完了するコード変更が合わさった瞬間にタスクステータスを「解決済み」に変更します。タグとワークボードのコラムは変更されません。

修復を使えるタイミング

ウィキメディアのウェブサイトの簡単な答え:タスクが「解決済み」として閉じられてから1週間から3週間の間。 詳細は wikitech:Deployments を参照してください。