「バグの報告」の版間の差分

2009年6月17日 (水) 23:03時点における版

すべてのアプリケーションにはバグがあります。あなたが気づこうが気づくまいが、それらは存在します。そして、人間がコードを書く限り、ソフトウェアの中にエラーは存在し続けるでしょう。しかし、些細なものであれ重大なものであれ、バグはアプリケーション開発の終わりを告げるものではありません。 — 実際はその正反対です。特に、オープンソース・プロジェクトにおいては、コミュニティの参加が開発の継続に不可欠です。フィードバックを与えてくれるユーザがいなければ、WordPressが今日のような発展を遂げることは、大変困難なものとなったでしょう。

すべての種類のフィードバック — それが真にバグであろうと、機能への要望であろうと — は同じ方法で報告されます。WordPressにバグや問題点を報告する方法を学ぶには、以下をお読みください。... you may also want to read Contributing to WordPress to find out how to contribute to the documentation and other areas of the WordPress project.

私たちはセキュリティ問題を防止すべくあらかじめ取り組んでいますが、(傲慢にも)それらが絶対に発生しないとは考えていません。もしあなたが、リリース中のWordPressにセキュリティ上の問題を発見した場合、secrity at the WordPress.org ドメインにメールを送ってください（訳注：メールアドレスに読み替える）。そうすれば、私たちは可能な限り早急に対処できるよう最善を尽くします。

セキュリティ問題を公表する前に、ベンダー(この場合、WordPressの開発者たち)に告知するのは模範的な手続きです。これにより、修正の準備が整い、脆弱性による公の被害を最小限に抑えることができます。

If you find a bug in a Plugin or Theme you are using with WordPress, do NOT report it using the procedures in this article! このページにある説明は、WordPress本体のバグにのみ適用されるものであり、プラグインのバグに対しては適用外です。

プラグインの公式リポジトリである WordPress Plugin Repository にあるプラグインは、WordPress本体とは 別のバグ追跡システム を採用しています。このシステムを使用するには Separate instructions が役立ちます。

公式リポジトリに属さないプラグインについては、プラグインに同梱されていたドキュメントを読んで、バグの報告先を調べてください。もし、バグ報告に関する情報が記載されていなかった場合、そのプラグインの開発者に直接連絡を取る必要があります。

Overview of Bug Reporting and Resolution

There are several steps in the process of reporting and resolving a WordPress bug. Here is an overview; more details are in sections below.

1. A user finds a bug that appears to be in the core of WordPress (not in a Theme or Plugin).
2. The user tries to make sure it is actually a bug. See Before You Report a Bug (below).
3. If it is determined to be a bug, the user submits the bug report, called a ticket, to Trac, the WordPress bug tracking system. See Reporting a Bug (below).
4. A WordPress developer (who could be a volunteer like you) confirms that the bug does actually exist, and that it should be fixed, and marks it as such in the ticket. See Trac Keywords list (below) and Bug Resolutions (below).
5. A WordPress developer (which could be you) decides to fix the bug. The developer may choose to take responsibility for the bug by clicking on the Accept ticket option near the bottom of the ticket, though this is not required. Then the developer figures out how to fix the bug, creates one or more patch files, and uploads them to Trac. See Patching Bugs (below). Also, if you want to help with fixing bugs, but don't know what bugs to fix, see Finding Bugs to Fix (below).
6. Members of the WordPress development group (including volunteers) test the patch, to see if it fixes the bug and doesn't break anything else. They add comments and keywords to the ticket to indicate their results. See Trac Keywords list (below).
7. One of the WordPress developers with authority to modify the official WordPress source code (Matt Mullenweg, Ryan Boren, Mark Jaquith or Peter Westwood) commits the patch to the core code in the SVN repository. They are more likely to do this if the bug and patch has been verified by someone they trust.
8. Finally, the person who commits the patch sets the bug ticket status to closed and the resolution to fixed. See Bug Resolutions (below).

The sections below add details to some of the steps outlined above.

WordPressのような大きなプロジェクトでは、多くのユーザがバグを送信するため、あなたのバグは既に送信されている可能性があります。このため、バグを送信する前に、それが未知の問題であることを確認することは非常に重要です。 If you are new to reporting bugs in WordPress, it is also a good idea to discuss the issue with more experienced developers before reporting it. Please follow the steps below.

1. あなたの発見したバグや要望を 公開または解決されたバグのリストから探す。
   • あなたが発見した問題が既に扱われていたら、重複してバグを報告しないでください。もし、あなたが更なる情報を寄与できる場合は、既存のバグノートに追加してください。
   • あなたが発見した問題と既に報告されている問題が、似てはいるがまったく同じではない場合、類似の問題のバグノートに追加するか、あるいは新規に提出するかは、あなたが判断して構いません。あなたの問題が新たに提出されるべきものかを判断するのは難しいかもしれませんが、既存の問題に対して、あなたが更なる情報を寄与するだけの場合、単純にその問題のバグノートに追加するのが普通です。もし、あなたの問題が十分に異なるものであったり、既に解決されたはずの問題が再発したりした場合は、新しいバグとして報告してください。
   • If your issue was recently reported and then closed, and you do not agree with the resolution, you can also reopen the ticket and add a comment as to your reasoning.
2. To discuss a bug before reporting it in Trac (e.g. to figure out if it is really a bug in the core of WordPress and not in a plugin or theme), you can post a question on the WordPress Support Forum, discuss your issue on the #wordpress IRC channel/en, or have an email discussion on the Testers/en or Hackers/en mailing list.

Trac is the name of the official WordPress bug tracker. It uses the open source bug tracking software Trac which is a product from Edgewall Software. Follow these steps to create a good bug report in Trac:

1. Read Before You Report a Bug (above), and verify that you have a new bug that is appropriate to report.
2. Read this article on How to Report Bugs Effectively, and the Trac Ticket documentation.
3. Log into WordPress Trac using your support forum username and password. If you don't have an account at the support forums, register so that you can login to Trac. This is essential for communication about your bug, since the developers may need more information (and you cannot create a ticket without logging in).
4. Click New Ticket in Trac to reach the bug reporting page.
5. Fill in the following fields on the new ticket page:

   Short Summary

   Make the summary short but informative and accurate, as this is the ticket title that will be displayed in search results.

   Full Description

   Fill in a full description of your bug or feature request. Include a description of the problem, steps someone else would have to take to reproduce the problem, maybe an example of the bug in action (i.e. a URL), and a description of why it is a problem worthy of being corrected. Also include information about your platform, such as operating system, web server software, PHP version, MySQL version, and WordPress version. The better your description, the better the chances of having the bug resolved promptly.

   Ticket Properties

   Priority

   You will need to decide on a priority for the issue -- this is how urgent the bug is. Unless it is a critical bug, this is best left to the default as developers will usually rank the bug's priority.

   Component

   Select the component of WordPress where the bug was found

   Severity 

   The significance of the issue. Select a severity based on how critical you consider the issue to be. If in doubt, leave this option as Normal.

   Assign to

   If you know of the developer who is responsible for the code that the bug is in, place their Trac username here. You can also take responsibility for the bug yourself, by putting your own Trac user name here. This is optional and could speed up developer attention to the bug.

   Milestone

   By what version this issue should be resolved, at the latest. Do not change this. This is an option that WordPress developers will set.

   Version

   The version of WordPress where the bug was found. You can find the version number of WordPress in the footer of the admin panel.

   Keywords

   Keywords that will make it easier for developers to find the bug, and identify the areas it affects. An example might be 'posting' for a bug involving the posting mechanism in WordPress. Also, there are some standard keywords used to flag your bug's status (see Trac Keywords below).

   CC

   Who bug information and updates should be sent to. If you want to be kept informed, enter your own Trac user name here. You will then be notified by email any time a change is made to this report, or a note to the bug is added. Don't ignore these emails; any time a change is made, be sure to check the report for updates. Developers may need further information from you, and this is their only way of getting in contact with you. Note: you need to go to the Trac Settings page to set your email address. Putting it into your Support Forum profile will not get it into Trac for purposes of CC messages. Note: If you are the bug's reporter, you will already get messages (if your email is known), so no need for CC.

6. Click Submit Ticket (after previewing it). Then pat yourself on the back.

If you want to fix bugs in the core parts of WordPress, but don't know which ones to fix, here are some suggestions on how to find bugs to fix:

• Look through the Needs Patch Report on Trac (which lists bugs that have not been marked with the "has_patch" keyword), the Lacks Attachment Report on Trac (which lists bugs that do not have a patch file attached), or other Trac reports for bugs that look interesting.
• Send an email message to the wp-hackers mailing list/en and ask how you can help.
• There is also sometimes bug triage on the #wordpress-dev IRC/en channel
• Occasionally there are bug days on #wordpress-bugs. You can read about what happens in a bug day in WordPress Bug Hunts/en, and subscribe to either the wp-hackers/en or wp-testers/en mailing list to find out when they happen.
• Consider joining the wp-trac email list to follow the discussions about each Trac Ticket.

If you are familiar with PHP and MySQL, and would like to help in the development of WordPress, then you are encouraged to patch WordPress bugs. Here are the steps to follow:

1. Read Finding Bugs to Fix (above), and find a bug to fix in Trac.
2. Connect to the WordPress Subversion (SVN) Repository using the username and password you acquired when registering. Read Using Subversion/en if you are unfamiliar with SVN. All patches should be submitted against the latest code in the SVN repository.
3. Figure out how to fix the bug, by modifying WordPress core files. You may want to discuss your proposed solution on the wp-hackers mailing list/en before finalizing it.
4. Test your fix, verifying that the bug has been fixed, and that nothing else in WordPress is broken in the process.
5. Create a patch file (or files) containing your fix. This is basically a diff of the fixed file(s) and the originals from SVN. See How to Patch WordPress by Owen Winkler for detailed instructions. There are also instructions for Linux/Mac command-line users in Mark Jaquith's Toolbox and Windows Tortoise SVN users in Westi's Blog.
6. Upload it to the ticket using the Trac Attach file button, and add has-patch to the keywords. If the patch needs testing, you might also put needs-testing, or one of the other Trac keywords; see Trac Keywords (below) for more information.

There are a number of keywords with defined meaning used in Trac that are commonly used; some are also searched for by Trac Reports.

reporter-feedback

A response is needed from the reporter. Further investigation is unlikely without a response to the questions from someone experiencing the problem.

has-patch

A solution to the ticket has been attached, and it is ready for review and/or committing.

needs-testing

Someone needs to test the solution.

2nd-opinion

Another person is needed to express an opinion about the problem or the solution.

dev-feedback

A response is wanted from a developer (not commonly used)

tested

The patch has been tested. When adding this tag please comment with the patch filename that was tested, how the patch was tested, and which version of WordPress was used (including the SVN revision number, if it is not an officially released version).

commit

The patch has been reviewed and tested by a trusted member of the development community; therefore the patch is ready to be added to the WordPress core files.

needs-patch

The ticket has been reviewed, found to be desirable to solve, and marked as especially needing a patch, or the submitted patch doesn't work and needs to be redone.

needs-unit-tests

The ticket has been reviewed, found to be desirable to solve and we would like some unit tests written to test the functionality and any patch that may exist before committing a change as the risk of causing other issues is high.

needs-doc

Inline documentation for the code is needed. These are either place holder tickets for individual files or tickets with patches for new functions which need documenting before they are committed.

A ticket in Trac starts its life in the open status, and (hopefully) is eventually closed. When a ticket is closed, it is marked with one of the following status designations:

• If your bug has been reported elsewhere, it will likely be closed with duplicate.
• If the bug has already been fixed in the latest subversion code (which is probably not what you're running unless you have a local test blog), then it will be closed with fixed.
• If it is decided that your bug isn't in fact a bug, but is the intended behaviour, it will be closed with invalid.
• If no-one else can replicate the symptoms you describe, it will be closed with worksforme.
• If your bug is a feature request that the developers don't want in the core, it will be marked as wontfix.

Please verify that your bug doesn't fall into one of these categories before submission.

• The processing of your bug may require your participation. Please be willing and prepared to aid the developers in resolving the issue.
• Don't be upset if your bug gets resolved as "Not a bug" or "Won't fix". What seems like a bug to you may very well be a "feature". These resolutions just mean "not going to fix now", maybe in the future it will be a priority to solve.
• Thank you for contributing to the development of WordPress!

最新英語版： WordPress Codex » Reporting Bugs （最新版との差分）