• 赤色のリンクは、まだ日本語Codexに存在しないページ・画像です。英語版と併せてご覧ください。(詳細

このWikiはいつでも誰でも編集できます

バグの報告

提供: WordPress Codex 日本語版
2008年4月4日 (金) 06:31時点におけるBono (トーク | 投稿記録)による版 (WPJ Codex データインポート(2005年4月6日 (水) 19:47 Carthik 版 en:Reporting Bugs))

移動先: 案内検索

このページ「バグの報告」は 情報が古くなっている可能性があります。最新版英語)も合わせてご覧ください。最新に更新してくださる協力者を求めています

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

すべての種類のフィードバック — それが真にバグであろうと、機能への要望であろうと — は同じ方法で報告されます。WordPressにバグや問題点を報告する方法を学ぶには、以下をお読みください。

Reporting security issues

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

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

A note about plugin bugs

このページにある説明は、WordPress本体のバグにのみ適用されるものであり、プラグインのバグに対しては適用外です。

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

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

Before you submit

WordPressのような大きなプロジェクトでは、多くのユーザがバグを送信するため、あなたのバグは既に送信されている可能性があります。このため、バグを送信する前に、それが未知の問題であることを確認することは非常に重要です。

  1. あなたの発見したバグや要望を 公開または解決されたバグのリストから探す。
    • あなたが発見した問題が既に扱われていたら、重複してバグを報告しないでください。もし、あなたが更なる情報を寄与できる場合は、既存のバグノートに追加してください。
    • あなたが発見した問題と既に報告されている問題が、似てはいるがまったく同じではない場合、類似の問題のバグノートに追加するか、あるいは新規に提出するかは、あなたが判断して構いません。あなたの問題が新たに提出されるべきものかを判断するのは難しいかもしれませんが、既存の問題に対して、あなたが更なる情報を寄与するだけの場合、単純にその問題のバグノートに追加するのが普通です。もし、あなたの問題が十分に異なるものであったり、既に解決されたはずの問題が再発したりした場合は、新しいバグとして報告してください。
  2. 次のガイドライン 効果的なバグ報告の方法 を読んでください。これは非常に情報に富んだ記事で、ここに挙げられている手続きはバグ報告システムをより効果的にするのに大いに役立つでしょう。

Submitting your bug to Mosquito

Mosquito is the name of the official WordPress bug tracker. It uses the open source bug tracking software Mantis. Follow these steps for creating a good bug report in Mosquito:

  1. If you do not already have an account on Mosquito, create one. This is essential for communication about your bug, since the developers may need more information from you after you submit.
  2. Once you've logged in, click Report Issue to view the bug reporting page. Fill out the following fields:
    Category 
    General categorization of the bug.
    Reproducibility 
    How consistently the bug appears. For feature requests, this should be N/A.
    Severity 
    The significance of the issue. Options are:
    Feature 
    A feature request.
    Trivial 
    Very non-critical; not an error per se, just a little better way of doing things.
    Text 
    Anything to do with text changes, spelling or grammar errors.
    Tweak 
    Extremely minor error in functionality, which differs only slightly from the way it should work.
    Minor 
    Minor error in functionality, non-fatal.
    Major 
    Major error in functionality, but still non-fatal.
    Crash 
    A fatal, critical error which prevents WordPress from functioning at all after the issue is encountered.
    Block 
    A fatal, critical error which prevents other bugs from being fixed, or which is a significant enough roadblock to prevent developers or testers from being able to continue until it is fixed.
    Priority 
    The urgency with which the issue should be addressed.
    Platform information 
    Advanced Report only. If your bug pertains to the way pages render in a particular browser, you should fill these fields in:
    Platform 
    Enter your browser name and version here. Be specific! If it has a build date or specific revision number, include that. Otherwise, specify the exact point release.
    OS 
    Operating system on which you are running the above browser.
    OS Version 
    Version of the operating system you're using. Be specific! Include service pack numbers, security updates, etc. If it has a build date or specific revision number, include that. Otherwise, specify the exact point release.
    Note: You can set up platform profiles in your Mosquito account for future availability under the Select Profile dropdown menu. Click My AccountProfiles to configure your saved profiles.
    Product Version 
    Select the version of WordPress you found the bug in.
    Product Build 
    Advanced Report only. Enter the specific WordPress version in which you found the bug. If you are testing a nightly, copy and paste the version string found in the footer of any Admin screen. If you are using a Subversion release, enter the revision number.
    Summary 
    A useful, descriptive sentence or phrase which describes the problem succinctly. Summaries should be like poetry: The goal is to maximize the amount of information you convey in the summary, while distilling it down into only the most essential words. If you're really good, you can work in words that imply circumstances and other information about a bug without explicitly saying it.
    Description 
    A more detailed description of the symptoms of the bug. (If you wrote a really good Summary, this should feel like a lot of rehashing.)
    Steps to Reproduce 
    Advanced Report only. A detailed account of all steps required to reproduce your bug. Once you're finished compiling your steps, be sure to follow them yourself and make sure you can reproduce it yourself using the steps you wrote.
    Additional Information 
    Use this field to specify the variables (settings, plugins, etc.), or just give additional information that's not actually a description of the bug.
    Upload File 
    If you have a patch to submit (yay!), use this to upload your diff. Then pat yourself on the back.
    View Status 
    Very rarely needed, but very important. If you are submitting a potential security vulnerability, the knowledge of which could make WordPress blogs everywhere vulnerable to attack, select Private. There is important protocol to follow when submitting security-related issues for software of any kind, and it involves containing knowledge of a potential vulnerability until developers have had a sufficient opportunity to distribute a fix. This helps minimize users' vulnerability until a fix is available.
    Report Stay 
    Check this if you have another bug to report immediately after you submit this one. (Be sure you've already searched for the next bug!)
  3. Click Submit Report. Then pat yourself on the back. (Even if you've already done so.)
  4. As the bug's Reporter, you will automatically be notified by email any time a change is made to this report, or a Bugnote 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.

Notes

  • 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."
  • Thank you for contributing to the development of WordPress!

最新英語版: WordPress Codex » Reporting Bugs最新版との差分