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

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

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

提供: WordPress Codex 日本語版
移動先: 案内、 検索
(翻訳一部追加)
細 (冒頭に英語のリファレンス移動を追記)
 
(他の1人の利用者による、間の1版が非表示)
1行目: 1行目:
−
{{NeedTrans||
+
{{Message|
−
 
+
| background = #FCECAD
−
* 最新英語版に差し替えました。
+
| border = #CCCCCC
−
* 翻訳済みだった部分は、コメントアウトされていた英文を最新版に差し替えただけです。履歴の差分表示か英文と見比べて、必要に応じて和訳を更新してください（言い回しの違いは直さなくて構いません）。
+
| color = #000000
 +
| text =英語版は次のURLに移動しました。最新版は[https://make.wordpress.org/core/handbook/reporting-bugs/ Reporting Bugs] をご覧ください。 なお、以下にある以前の日本語訳は残しますが、内容が古くなっている可能性があります。
 
}}
 
}}
 +
 +
#REDIRECT [https://make.wordpress.org/core/handbook/reporting-bugs/]
 +
  
 
すべてのアプリケーションには[http://ja.wikipedia.org/wiki/バグ バグ]があります。人間がコードを書く限り、ソフトウェア中のエラーがなくなることはないでしょう。エラーには些細なものあれば、重大なもあります。[[WordPress]] のようなオープンソース・プロジェクトにおいては、新しい機能を計画するのと同じように、バグを確認するためにユーザーコミュニティの参加が不可欠です。
 
すべてのアプリケーションには[http://ja.wikipedia.org/wiki/バグ バグ]があります。人間がコードを書く限り、ソフトウェア中のエラーがなくなることはないでしょう。エラーには些細なものあれば、重大なもあります。[[WordPress]] のようなオープンソース・プロジェクトにおいては、新しい機能を計画するのと同じように、バグを確認するためにユーザーコミュニティの参加が不可欠です。
 
<!--Every application has [[Wikipedia:Computer bug|bugs]] -- as long as humans write code, there will continue to be errors in software. Some errors are trivial, while others are critical. Open-source projects like [[WordPress]] need the participation of their user communities to identify bugs in their software, as well as to plan for new features.-->
 
<!--Every application has [[Wikipedia:Computer bug|bugs]] -- as long as humans write code, there will continue to be errors in software. Some errors are trivial, while others are critical. Open-source projects like [[WordPress]] need the participation of their user communities to identify bugs in their software, as well as to plan for new features.-->
  
−
WordPress プロジェクトでは（実際のバグであろうが、新機能の要望であろうが）どんな種類のフィードバックも報告する方法は同じです。WordPress のバグや問題点を報告する方法を知るには、以下をお読みください。また、よかったら[[WordPress への協力|Contributing to WordPress]]のページもドキュメンテーションやその他の部分でプロジェクトに協力する方法も読んでみてください。
+
WordPress プロジェクトでは、純粋なバグでも新機能の要望でも、すべての種類のフィードバックを同じ方法で報告するようになっています。WordPress のバグや問題点を報告する方法を知るには、このページを読み進めてください。また、ドキュメンテーションなどの部分でプロジェクトに協力する手段を知りたい方は、[[WordPress への協力]]ページも読んでみてください。
 
<!--All types of feedback &mdash; whether they're genuine bugs or feature requests &mdash; are reported the same way in the WordPress project. Read on to learn how to report bugs and issues for 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.-->
 
<!--All types of feedback &mdash; whether they're genuine bugs or feature requests &mdash; are reported the same way in the WordPress project. Read on to learn how to report bugs and issues for 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.-->
  
15行目: 19行目:
 
</div>
 
</div>
  
−
私たちはセキュリティ問題を防止するための積極的な取り組みをおこなっていますが、問題が絶対に発生しないとは考えていません。もしリリース済みバージョンの WordPress にセキュリティ上の問題を発見した場合、<code>secrity</code> at the <code>WordPress.org</code> ドメインにメールを送ってください（訳注：メールアドレスに読み替える）。できるだけ早急に対処できるよう最善を尽くします。
+
私たちはセキュリティ問題を防止するための積極的な取り組みを行っていますが、絶対に問題が発生しないとは考えているわけではありません。もしリリース済みバージョンの WordPress にセキュリティ上の問題を発見した場合、<code>security</code> アット <code>WordPress.org</code> へメールを送ってください（訳注：メールアドレスに読み替える）。できるだけ早急に対処できるよう最善を尽くします。
 
<!--While we try to be proactive in preventing security problems, we do not assume they'll never come up. If you believe you've found a security problem in a release of WordPress please send mail to <tt>security</tt> at the <tt>WordPress.org</tt> domain and we'll do our best to address it as soon as possible.-->
 
<!--While we try to be proactive in preventing security problems, we do not assume they'll never come up. If you believe you've found a security problem in a release of WordPress please send mail to <tt>security</tt> at the <tt>WordPress.org</tt> domain and we'll do our best to address it as soon as possible.-->
  
−
修正の準備を整え、脆弱性による一般ユーザーの被害を最小限に抑えるため、セキュリティ問題を公表する前にベンダー（この場合、WordPress の開発者）に告知するのは標準的な習慣です。
+
修正の準備を整え、脆弱性による一般ユーザーの被害を最小限に抑えられるよう、セキュリティ問題を公表する前に提供元（この場合、WordPress の開発者）に告知するのは標準的な習慣です。
 
<!--It is standard practice to notify the vendor (the WordPress developers, in this case) of a security problem before publicizing so a fix can be prepared and public damage due to the vulnerability minimized. -->
 
<!--It is standard practice to notify the vendor (the WordPress developers, in this case) of a security problem before publicizing so a fix can be prepared and public damage due to the vulnerability minimized. -->
  
53行目: 57行目:
 
</div>
 
</div>
  
−
The sections below add details to some of the steps outlined above.
+
以下のセクションでは、上記で説明された内容についてさらに詳しく説明しています。
  
 
<div id="Before_You_Report_a_Bug">
 
<div id="Before_You_Report_a_Bug">
65行目: 69行目:
 
#*発見した問題が既に扱われていたら、重複してバグを報告しないでください。もし、追加情報を寄与できる場合は、既存のバグノートに追加してください。
 
#*発見した問題が既に扱われていたら、重複してバグを報告しないでください。もし、追加情報を寄与できる場合は、既存のバグノートに追加してください。
 
#*発見した問題と既に報告されている問題が、似てはいるがまったく同じではない場合、類似の問題のバグノートに追加するか、あるいは新規に提出するかは、あなたが判断して構いません。あなたの問題が新たに提出されるべきものかを判断するのは難しいかもしれませんが、既存の問題に対して、あなたが更なる情報を寄与するだけの場合、単純にその問題のバグノートに追加するのが普通です。もし、あなたの問題が十分に異なるものであったり、既に解決されたはずの問題が再発したりした場合は、新しいバグとして報告してください。
 
#*発見した問題と既に報告されている問題が、似てはいるがまったく同じではない場合、類似の問題のバグノートに追加するか、あるいは新規に提出するかは、あなたが判断して構いません。あなたの問題が新たに提出されるべきものかを判断するのは難しいかもしれませんが、既存の問題に対して、あなたが更なる情報を寄与するだけの場合、単純にその問題のバグノートに追加するのが普通です。もし、あなたの問題が十分に異なるものであったり、既に解決されたはずの問題が再発したりした場合は、新しいバグとして報告してください。
−
#* 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.
+
#*最近チケットが作成され、''closed'' になった問題に関して解決方法に納得がいかない場合、チケットを再度開いてその理由のコメントを追加できます。
−
# 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 [http://wordpress.org/support/ WordPress Support Forum], discuss your issue on the [[WordPress IRC Live Help|#wordpress IRC channel]]/[[:en:WordPress IRC Live Help|en]], or have an email discussion on the [[Mailing Lists#Testers|Testers]]/[[:en:Mailing Lists#Testers|en]] or [[Mailing Lists#hackers|Hackers]]/[[:en:Mailing Lists#hackers|en]] mailing list.
+
# Trac でチケットを再度開く前にバグについて話し合いたい場合（例: プラグインやテーマのせいで発生する現象なのか、それとも本当に WordPress コアのバグなのか解明する）は、質問を [http://wordpress.org/support/ WordPress Support Forum]（または[http://ja.forums.wordpress.org/ 日本語サポートフォーラム]）や [[WordPress IRC Live Help|#wordpress IRC channel]]/[[:en:WordPress IRC Live Help|en]] に投稿したり、[[Mailing Lists#Testers|Testers]]・[[Mailing Lists#hackers|Hackers]] メーリングリストで話し合うと良いでしょう。
 
<!--# Search for your bug or feature request in Trac by using [http://trac.wordpress.org/search Search] or a [http://trac.wordpress.org/query Query].
 
<!--# Search for your bug or feature request in Trac by using [http://trac.wordpress.org/search Search] or a [http://trac.wordpress.org/query Query].
 
#* If your issue has already been reported, please do not report a duplicate bug. If you have further information to contribute, log in and add a note to the existing bug.
 
#* If your issue has already been reported, please do not report a duplicate bug. If you have further information to contribute, log in and add a note to the existing bug.
77行目: 81行目:
 
</div>
 
</div>
  
−
[http://trac.wordpress.org/ Trac] is the name of the official WordPress bug tracker. It uses the open source bug tracking software [http://projects.edgewall.com/trac/ Trac] which is a product from [http://www.edgewall.com/ Edgewall Software]. Follow these steps to create a good bug report in Trac:
+
公式 WordPress バグトラッカーは [http://trac.wordpress.org/ Trac] と呼ばれています。[http://www.edgewall.com/ Edgewall Software] の製品で、オープンソースバグトラッキングシステムである [http://projects.edgewall.com/trac/ Trac] を使っています。Trac で良いバグ報告を行うには、以下のステップに従ってください。
  
−
# Read [[#Before You Report a Bug|Before You Report a Bug (above)]], and verify that you have a new bug that is appropriate to report.
+
# 上記の[[#Before You Report a Bug|バグを報告する前に]]セクションを読んで、報告するにふさわしい新しいバグを発見したかどうかを検証する。
−
# Read this article on [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively], and the [http://trac.wordpress.org/wiki/TracTickets Trac Ticket documentation].
+
# [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively]、[http://trac.wordpress.org/wiki/TracTickets Trac Ticket ドキュメンテーション]を読む。
−
# Log into [http://trac.wordpress.org/ WordPress Trac] using your [http://wordpress.org/support/ support forum] username and password. If you don't have an account at the support forums, [http://wordpress.org/support/register.php 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).
+
# [http://wordpress.org/support/ サポートフォーラム]（または[http://ja.forums.wordpress.org/ 日本語サポートフォーラム]）のユーザー名とパスワードを使って [http://trac.wordpress.org/ WordPress Trac] にログインする。アカウントを持っていない場合は、[http://ja.forums.wordpress.org/register.php 新規登録]する。開発者が詳しい情報を必要としている場合があり、ログインしないとチケットを作成できないため、このステップはバグに関してのコミュニケーションには欠かせません。
−
# Click '''[http://trac.wordpress.org/newticket New Ticket]''' in Trac to reach the bug reporting page.
+
# Trac で '''[http://trac.wordpress.org/newticket New Ticket]''' をクリックし、バグ報告ページへ移動する。
 
# チケット新規作成ページで以下の情報を記入する。
 
# チケット新規作成ページで以下の情報を記入する。
 
#; Short Summary（概要）: 概要はチケットのタイトルになり、検索結果に表示されることになるので、短くかつ説明的で正確になものにしましょう。
 
#; Short Summary（概要）: 概要はチケットのタイトルになり、検索結果に表示されることになるので、短くかつ説明的で正確になものにしましょう。
 
#; Full Description（説明）: バグまたは新機能要望の完全な説明を記入しましょう。問題の説明、同様の問題を再現するための手順、（もしあれば）実際のバグが見られる URL など、そして、この問題を修正する価値がある理由を含めてください。また、OS、サーバーの種類、PHP・MySQL・WordPress のバージョンなどあなたの環境についても説明しましょう。説明が良いものであればあるほど、バグがすばやく解決される可能性が高くなるでしょう。
 
#; Full Description（説明）: バグまたは新機能要望の完全な説明を記入しましょう。問題の説明、同様の問題を再現するための手順、（もしあれば）実際のバグが見られる URL など、そして、この問題を修正する価値がある理由を含めてください。また、OS、サーバーの種類、PHP・MySQL・WordPress のバージョンなどあなたの環境についても説明しましょう。説明が良いものであればあるほど、バグがすばやく解決される可能性が高くなるでしょう。
 
#; Ticket Properties（チケットの属性）:
 
#; 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.
+
#:; Priority（優先度）: 問題の優先度について決定します。これはバグの修正にどれだけ緊急度を要するかを示します。たいていは開発者が決定してくれるので、重大なバグでないかぎりデフォルトの状態のままにしておくのが良いでしょう。
−
#:; Component（コンポーネント）: Select the component of WordPress where the bug was found
+
#:; Component（コンポーネント）: バグのある WordPress の部分を選択します。
−
#:; 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''.
+
#:; Severity（重要度): 問題の ''重要度''。はっきりしない場合は '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.
+
#:; Assign to（担当者）: バグのあるコードの担当開発者を知っている場合は、その人の Trac ユーザー名を入力します。自分のユーザー名を入れて、バグ修正を担当することもできます。これはオプションですが、記入することで開発者がすぐにバグに注意を払ってくれるかもしれません。
−
#:; 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.
+
#:; Milestone（マイルストーン）: 遅くともこのマイルストーンまでに問題を解決するべきというバージョン。WordPress 開発者が設定するオプションのため、変更はしないでください。
−
#:; 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.
+
#:; Version（バージョン）: バグが見つかった WordPress のバージョン。管理画面のフッターでバージョンを確認できます。
−
#:; 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|Trac Keywords]] below).
+
#:; Keywords（キーワード）: 開発者がバグを発見し、影響がある部分を確認しやすくするためのキーワード。例えば投稿機能の場合は 'posting' など。また、バグの状態に関する標準キーワードもあります（以下の [[#Trac Keywords|Trac キーワード]]を参照）。
−
#:; 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 [http://trac.wordpress.org/ticket/8890 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.
+
#:; CC: バグの情報や更新状況を送るユーザー。情報を追いたい場合は、自分のユーザー名を入れてください。チケットに変更が加えられたときやコメントが追加された時にメールで通知されます。通知があった場合には無視せず、チケットの内容を確認してください。開発者はチケット以外で連絡を取ることができませんが、ここで追加情報を必要としているかもしれません。<br />'''注1''': Trac の ''Preferences'' ページでメールアドレスを設定してください。サポートフォーラムのプロフィールにアドレスを入れても、Trac の CC メッセージは [http://trac.wordpress.org/ticket/8890 届きません]。<br />'''注2''': メールアドレスを設定しているバグの報告者には自動的にメールが届きますので、CC に入力する必要はありません。
−
# Click '''Submit Ticket''' (after previewing it). Then pat yourself on the back.
+
# プレビュー後、'''Submit Ticket''' をクリックします。それから、「おつかれさま！」と自分の肩を叩いてあげてください。
  
 
<div id="Finding_Bugs_to_Fix">
 
<div id="Finding_Bugs_to_Fix">
101行目: 105行目:
 
</div>
 
</div>
  
−
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:
+
WordPress コアのバグを修正したいけれど、どれに手を付けていいか分からない…という場合、以下を読んでみてください。
−
* Look through the [http://trac.wordpress.org/report/13 Needs Patch Report on Trac] (which lists bugs that have not been marked with the "has_patch" keyword), the [http://trac.wordpress.org/report/18 Lacks Attachment Report on Trac] (which lists bugs that do not have a patch file attached), or other [http://trac.wordpress.org/report Trac reports] for bugs that look interesting.
+
 
−
* Send an email message to the [[Mailing Lists#Hackers|wp-hackers mailing list]]/[[:en:Mailing Lists#Hackers|en]] and ask how you can help.
+
* [http://trac.wordpress.org/report/13 Trac の "Needs Patch" レポート]（"has_patch" キーワードがついていないバグ報告）、[http://trac.wordpress.org/report/18 Trac の "Lacks Attachment" レポート]（パッチファイルが添付されていないバグ報告）、その他の [http://trac.wordpress.org/report Trac レポート]に目を通し、興味のあるバグを見つける。
−
* There is also sometimes bug triage on the <tt>#wordpress-dev</tt> [[IRC]]/[[:en:IRC|en]] channel
+
* [[Mailing Lists#Hackers|wp-hackers メーリングリスト]]にメールを送り、協力したいことを伝える。
−
* Occasionally there are bug days on <tt>#wordpress-bugs</tt>. You can read about what happens in a bug day in [[WordPress Bug Hunts]]/[[:en:WordPress Bug Hunts|en]], and subscribe to either the [[Mailing Lists#Hackers|wp-hackers]]/[[:en:Mailing Lists#Hackers|en]] or [[Mailing Lists#Testers|wp-testers]]/[[:en:Mailing Lists#Testers|en]] mailing list to find out when they happen.
+
* 時々、<tt>#wordpress-dev</tt> [[IRC]]/[[:en:IRC|en]] チャンネルでバグの修正順序決定を行うこともあります。
−
* Consider joining the [http://lists.automattic.com/mailman/listinfo/wp-trac wp-trac email list] to follow the discussions about each [http://trac.wordpress.org/report Trac Ticket].
+
* たまに <tt>#wordpress-bugs</tt> IRC チャンネルでバグ Day が開かれます。バグ Day について詳しくは、[[WordPress Bug Hunts]]/[[:en:WordPress Bug Hunts|en]] を読むと良いでしょう。また、実施日について知りたければ [[Mailing Lists#Hackers|wp-hackers]] または [[Mailing Lists#Testers|wp-testers]] メーリングリストを購読してください。
 +
* 各 [http://trac.wordpress.org/report Trac チケット]に関するディスカッションを追うには、[http://lists.automattic.com/mailman/listinfo/wp-trac wp-trac メーリングリスト]への参加を検討してみてください。
  
 
<div id="Patching_Bugs">
 
<div id="Patching_Bugs">
112行目: 117行目:
 
</div>
 
</div>
  
−
If you are familiar with [[用語集#PHP|PHP]] and [[用語集#MySQL|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:
+
[[用語集#PHP|PHP]] や [[用語集#MySQL|MySQL]] をよく知っていて WordPress の開発に協力したい場合は、バグのパッチ作成をお勧めします。以下のステップに従ってください。
  
−
#Read [[#Finding Bugs to Fix|Finding Bugs to Fix (above)]], and find a bug to fix in [http://trac.wordpress.org Trac].
+
#上記の[[#Finding Bugs to Fix|修正するバグを見つける]]を読み、[http://trac.wordpress.org Trac] で修正するバグを見つけます。
−
#Connect to the [http://wordpress.org/download/svn/ WordPress Subversion (SVN) Repository] using the username and password you acquired when [http://wordpress.org/support/register.php registering]. Read [[Using Subversion]]/[[:en:Using Subversion|en]] if you are unfamiliar with SVN.  All patches should be submitted against the latest code in the SVN repository.
+
#[http://wordpress.org/support/register.php 登録]（[http://ja.forums.wordpress.org/register.php 日本語]）したユーザー名とパスワードを使って[http://wordpress.org/download/svn/ WordPress Subversion (SVN) レポジトリ] に接続します。SVN を使ったことがない場合は、[[Subversion の使い方]]/[[:en:Using Subversion|en]] を読んでください。すべてのパッチは SVN レポジトリの最新コードに対して当てられるべきです。
−
# Figure out how to fix the bug, by modifying WordPress core files. You may want to discuss your proposed solution on the [[Mailing Lists#Hackers|wp-hackers mailing list]]/[[:en:Mailing_Lists#Hackers|en]] before finalizing it.
+
# WordPress コアファイルを編集してバグを修正する方法を探します。仕上げる前に、[[Mailing Lists#Hackers|wp-hackers メーリングリスト]]で、提案したい解決方法を話し合った方が良いかもしれません。
−
# Test your fix, verifying that the bug has been fixed, and that nothing else in WordPress is broken in the process.
+
# バグが直っているか、WordPress の他の部分に悪影響を与えていないかを検証するため、修正のテストを行います。
−
# 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 [http://asymptomatic.net/2005/12/03/586/how-to-patch-wordpress How to Patch WordPress by Owen Winkler] for detailed instructions. There are also instructions for Linux/Mac command-line users in [http://markjaquith.wordpress.com/2005/11/02/my-wordpress-toolbox/ Mark Jaquith's Toolbox] and Windows Tortoise SVN users in [http://blog.ftwr.co.uk/archives/2005/11/03/windows-wordpress-toolbox/ Westi's Blog].
+
# 修正を含む''パッチファイル''を作成します。基本的にはこれは SVN の元ファイルと修正部分の ''diff'' です。詳しくは [http://asymptomatic.net/2005/12/03/586/how-to-patch-wordpress How to Patch WordPress by Owen Winkler] をご覧ください。また、Linux/Mac コマンドラインユーザー向けには、[http://markjaquith.wordpress.com/2005/11/02/my-wordpress-toolbox/ Mark Jaquith's Toolbox] が、Windows Tortoise SVN ユーザー向けには [http://blog.ftwr.co.uk/archives/2005/11/03/windows-wordpress-toolbox/ Westi のブログ]上に説明があります。
−
# Upload it to the ticket using the [http://trac.wordpress.org/ 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|Trac Keywords (below)]] for more information.
+
# このパッチファイルを [http://trac.wordpress.org/ Trac] の ''Attach file'' ボタンを使ってアップロードし、''has-patch'' というキーワードを追加します。例えばパッチのテストが必要な場合は、''needs-testing'' など、その他の [[#Trac Keywords|Trac キーワード]]（下記）も必要に応じて加えましょう。
  
 
<div id="Trac_Keywords">
 
<div id="Trac_Keywords">
125行目: 130行目:
 
</div>
 
</div>
  
−
There are a number of keywords with defined meaning used in [http://trac.wordpress.org Trac] that are commonly used; some are also searched for by [http://trac.wordpress.org/report Trac Reports].
+
[http://trac.wordpress.org Trac] には、よく使われる定義済みのキーワードが複数あります。このうち一部は [http://trac.wordpress.org/report Trac Reports] で検索できます。
  
 
;reporter-feedback（要報告者フィードバック）
 
;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（パッチあり）
 
;has-patch（パッチあり）
−
: A solution to the ticket has been attached, and it is ready for review and/or committing.
+
: チケットの解決策がパッチとしてアップロードされていて、レビューまたはコミット待ちの状態。
 
;needs-testing（要テスト）
 
;needs-testing（要テスト）
−
: Someone needs to test the solution.
+
: 解決策のテストが必要。
 
;2nd-opinion（要意見）
 
;2nd-opinion（要意見）
−
: Another person is needed to express an opinion about the problem or the solution.
+
: 問題または解決策に関する第三者の意見が必要。
−
;dev-feedback（要開発者フィードバック）  
+
;dev-feedback（要開発者フィードバック）
−
: A response is wanted from a developer (not commonly used)
+
: 開発者からのフィードバックが必要（あまり使われないキーワード）
 
;tested（テスト済み）
 
;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).
+
: パッチがテスト済み。このキーワードを追加する場合は、パッチのファイル名・テスト実施の状況・テストを行った WordPress のバージョンをコメントに記入すること（公式リリースバージョンでない場合は、SVN リビジョン番号も含める）。
 
;commit（コミット可）
 
;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.
+
: パッチが開発コミュニティで信頼されているメンバーによってレビューおよびテストされ、WordPress コアファイルに追加できる状態。
 
;needs-patch（要パッチ）
 
;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（要ユニットテスト）
 
;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（要ドキュメンテーション）
 
;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.
+
: コードのインラインドキュメンテーションが必要。個別ファイル用のプレースホルダー、またはコミットの前にドキュメンテーションが必要な新規機能のパッチを含むチケット。
  
 
<div id="Bug_Resolutions">
 
<div id="Bug_Resolutions">
152行目: 157行目:
 
</div>
 
</div>
  
−
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:
+
Trac のチケットはまず ''open'' 状態からスタートし、（うまくいけば）最終的には ''closed'' になります。チケットがクローズされる場合、以下のいずれかになります。
  
−
* If your bug has been reported elsewhere, it will likely be closed with ''duplicate''.
+
* バグがすでに他で報告済みの場合、たいていは ''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''.
+
* バグが最新の Subversion コード（テスト環境でない場合はこのコードをお使いではないでしょう）中ですでに修正済みの場合、''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''.
+
* 報告したバグが実際にはバグではなく意図された動作の場合、''invalid'' としてクローズされます。
−
* If no-one else can replicate the symptoms you describe, it will be closed with ''worksforme''.
+
* 他の人が説明した状況を再現できない場合、''worksforme'' としてクローズされます。
−
* If your bug is a feature request that the developers don't want in the core, it will be marked as ''wontfix''.
+
* バグではなく開発者がコアには入れるつもりがない機能の要望だった場合、''wontfix'' としてクローズされます。
  
−
Please verify that your bug doesn't fall into one of these categories before submission.
+
報告する前に、バグがこれらに当てはまらないことを検証してください。
  
 
<div id="Notes">
 
<div id="Notes">
166行目: 171行目:
 
</div>
 
</div>
  
−
* バグの処理には協力が必要な場合があります。問題を解決するために開発者を補助をする心づもりをしておいてください。
+
* バグの処理には協力が必要な場合があります。問題を解決するために開発者への協力をする心づもりをしておいてください。
 
* 報告した問題が "Not a bug（バグではない）" や "Won't fix（修正しない）" という解決方法に落ち着いたとしても、気を悪くしないでください。あなたにとってバグと思われることは、そういう「機能」かもしれないということは十分あり得ます。これらの解決方法は単に「現在は修正するつもりはない」ということですので、将来優先的に直される可能性もあります。
 
* 報告した問題が "Not a bug（バグではない）" や "Won't fix（修正しない）" という解決方法に落ち着いたとしても、気を悪くしないでください。あなたにとってバグと思われることは、そういう「機能」かもしれないということは十分あり得ます。これらの解決方法は単に「現在は修正するつもりはない」ということですので、将来優先的に直される可能性もあります。
 
* WordPress の開発へのご協力ありがとうございます！
 
* WordPress の開発へのご協力ありがとうございます！

2015年8月15日 (土) 12:33時点における最新版

英語版は次のURLに移動しました。最新版はReporting Bugs をご覧ください。 なお、以下にある以前の日本語訳は残しますが、内容が古くなっている可能性があります。
  1. REDIRECT [1]


すべてのアプリケーションにはバグがあります。人間がコードを書く限り、ソフトウェア中のエラーがなくなることはないでしょう。エラーには些細なものあれば、重大なもあります。WordPress のようなオープンソース・プロジェクトにおいては、新しい機能を計画するのと同じように、バグを確認するためにユーザーコミュニティの参加が不可欠です。

WordPress プロジェクトでは、純粋なバグでも新機能の要望でも、すべての種類のフィードバックを同じ方法で報告するようになっています。WordPress のバグや問題点を報告する方法を知るには、このページを読み進めてください。また、ドキュメンテーションなどの部分でプロジェクトに協力する手段を知りたい方は、WordPress への協力ページも読んでみてください。

私たちはセキュリティ問題を防止するための積極的な取り組みを行っていますが、絶対に問題が発生しないとは考えているわけではありません。もしリリース済みバージョンの WordPress にセキュリティ上の問題を発見した場合、security アット WordPress.org へメールを送ってください（訳注：メールアドレスに読み替える）。できるだけ早急に対処できるよう最善を尽くします。

修正の準備を整え、脆弱性による一般ユーザーの被害を最小限に抑えられるよう、セキュリティ問題を公表する前に提供元（この場合、WordPress の開発者）に告知するのは標準的な習慣です。

プラグインとテーマのバグの報告

WordPress で使っているプラグインやテーマのバグを発見した場合は、このページにある方法での報告を行わないでください。このページの説明は WordPress 本体のバグにのみ適用されるものであり、プラグインやテーマのバグに対しては適用外です。

プラグインの公式リポジトリである WordPress Plugin Repository にあるプラグインは、WordPress本体とは 別のバグ追跡システム を採用しています。このシステムの使い方については、別途に TracTickets の取扱説明書が用意されています。

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

バグの報告と解決の概要

WordPress のバグ報告と解決には、複数の手順があります。以下が概要となります。詳細はさらに続きを読んでください。

  1. ユーザーが（テーマやプラグインではなく）WordPress 本体のバグを発見する。
  2. それが実際にバグかどうか確認する。下記のバグを報告する前にをご覧ください。
  3. もしバグであることが確実になったら、チケットと呼ばれるバグ報告を WordPress のバグ追跡システムである Trac に送信する。下記のバグの報告をご覧ください。
  4. WordPress 開発者（この人もあなたのように、ボランティアかもしれません）がバグの存在を確認し、修正するべきと判断し、チケットにそのことを記録します。下記のTrac キーワード一覧とバグの解決をご覧ください。
  5. WordPress 開発者（あなた自身ということもありえます）が、このバグを修正することにします。チケットページの最後の方にあるAccept ticket（チケットを受理）をクリックしてバグの責任を負うことを選ぶことができますが、これば必須ではありません。それからその開発者はどうやってバグを修正するかを考え、ひとつまたは複数のパッチファイルを作成し、そのファイルを Trac にアップロードします。下記のバグのパッチ作業をご覧ください。また、バグ修正に協力したいけれどどのバグを直していいか分からない場合は、以下の修正するバグを見つけるをご覧ください。
  6. WordPress 開発グループのメンバー（ボランティアも含む）がパッチをテストし、バグが修正されているか、その他の部分に悪影響がないかを確認します。結果を知らせるため、チケットにコメントやキーワードを追加します。下記のTrac キーワード一覧をご覧ください。
  7. 公式な WordPress のソースコードを編集する権限がある主要開発者（公式サイトの Lead Developers 参照）のうちの誰かが SVN リポジトリへパッチをコミットします。主要開発者は、バグやパッチが信頼のおける人によって検証された場合にこの作業を行う可能性が高いでしょう。
  8. 最後に、パッチをコミットした人がバグチケットのステータスを closed に、解決法を fixed（修正済み） に変更します。下記のバグの解決プロセスをご覧ください。

バグの報告と解決の詳細

以下のセクションでは、上記で説明された内容についてさらに詳しく説明しています。

バグを報告する前に

WordPress のような大きなプロジェクトでは、多くのユーザがバグを報告しているため、あなたが発見したバグは既に報告されている可能性があります。このため、バグを報告する前にそれがまだバグ追跡システム内に存在しない問題であることを確認することは非常に重要です。WordPress のバグ報告にまだなじみがないようでしたら、経験がある他の開発者に話してみるのがよいでしょう。以下の手順に従ってください。

  1. 発見したバグや要望を 公開または解決されたバグのリストから探す。
    • 発見した問題が既に扱われていたら、重複してバグを報告しないでください。もし、追加情報を寄与できる場合は、既存のバグノートに追加してください。
    • 発見した問題と既に報告されている問題が、似てはいるがまったく同じではない場合、類似の問題のバグノートに追加するか、あるいは新規に提出するかは、あなたが判断して構いません。あなたの問題が新たに提出されるべきものかを判断するのは難しいかもしれませんが、既存の問題に対して、あなたが更なる情報を寄与するだけの場合、単純にその問題のバグノートに追加するのが普通です。もし、あなたの問題が十分に異なるものであったり、既に解決されたはずの問題が再発したりした場合は、新しいバグとして報告してください。
    • 最近チケットが作成され、closed になった問題に関して解決方法に納得がいかない場合、チケットを再度開いてその理由のコメントを追加できます。
  2. Trac でチケットを再度開く前にバグについて話し合いたい場合（例: プラグインやテーマのせいで発生する現象なのか、それとも本当に WordPress コアのバグなのか解明する）は、質問を WordPress Support Forum（または日本語サポートフォーラム）や #wordpress IRC channel/en に投稿したり、Testers・Hackers メーリングリストで話し合うと良いでしょう。

バグの報告

公式 WordPress バグトラッカーは Trac と呼ばれています。Edgewall Software の製品で、オープンソースバグトラッキングシステムである Trac を使っています。Trac で良いバグ報告を行うには、以下のステップに従ってください。

  1. 上記のバグを報告する前にセクションを読んで、報告するにふさわしい新しいバグを発見したかどうかを検証する。
  2. How to Report Bugs Effectively、Trac Ticket ドキュメンテーションを読む。
  3. サポートフォーラム（または日本語サポートフォーラム）のユーザー名とパスワードを使って WordPress Trac にログインする。アカウントを持っていない場合は、新規登録する。開発者が詳しい情報を必要としている場合があり、ログインしないとチケットを作成できないため、このステップはバグに関してのコミュニケーションには欠かせません。
  4. Trac で New Ticket をクリックし、バグ報告ページへ移動する。
  5. チケット新規作成ページで以下の情報を記入する。
    Short Summary（概要）
    概要はチケットのタイトルになり、検索結果に表示されることになるので、短くかつ説明的で正確になものにしましょう。
    Full Description（説明）
    バグまたは新機能要望の完全な説明を記入しましょう。問題の説明、同様の問題を再現するための手順、（もしあれば）実際のバグが見られる URL など、そして、この問題を修正する価値がある理由を含めてください。また、OS、サーバーの種類、PHP・MySQL・WordPress のバージョンなどあなたの環境についても説明しましょう。説明が良いものであればあるほど、バグがすばやく解決される可能性が高くなるでしょう。
    Ticket Properties（チケットの属性）
    Priority（優先度）
    問題の優先度について決定します。これはバグの修正にどれだけ緊急度を要するかを示します。たいていは開発者が決定してくれるので、重大なバグでないかぎりデフォルトの状態のままにしておくのが良いでしょう。
    Component（コンポーネント）
    バグのある WordPress の部分を選択します。
    Severity（重要度)
    問題の 重要度。はっきりしない場合は 'Normal のままにしておきましょう。
    Assign to（担当者）
    バグのあるコードの担当開発者を知っている場合は、その人の Trac ユーザー名を入力します。自分のユーザー名を入れて、バグ修正を担当することもできます。これはオプションですが、記入することで開発者がすぐにバグに注意を払ってくれるかもしれません。
    Milestone（マイルストーン）
    遅くともこのマイルストーンまでに問題を解決するべきというバージョン。WordPress 開発者が設定するオプションのため、変更はしないでください。
    Version（バージョン）
    バグが見つかった WordPress のバージョン。管理画面のフッターでバージョンを確認できます。
    Keywords（キーワード）
    開発者がバグを発見し、影響がある部分を確認しやすくするためのキーワード。例えば投稿機能の場合は 'posting' など。また、バグの状態に関する標準キーワードもあります（以下の Trac キーワードを参照）。
    CC
    バグの情報や更新状況を送るユーザー。情報を追いたい場合は、自分のユーザー名を入れてください。チケットに変更が加えられたときやコメントが追加された時にメールで通知されます。通知があった場合には無視せず、チケットの内容を確認してください。開発者はチケット以外で連絡を取ることができませんが、ここで追加情報を必要としているかもしれません。
    注1: Trac の Preferences ページでメールアドレスを設定してください。サポートフォーラムのプロフィールにアドレスを入れても、Trac の CC メッセージは 届きません。
    注2: メールアドレスを設定しているバグの報告者には自動的にメールが届きますので、CC に入力する必要はありません。
  6. プレビュー後、Submit Ticket をクリックします。それから、「おつかれさま！」と自分の肩を叩いてあげてください。

修正するバグを見つける

WordPress コアのバグを修正したいけれど、どれに手を付けていいか分からない…という場合、以下を読んでみてください。

バグのパッチ作業

PHP や MySQL をよく知っていて WordPress の開発に協力したい場合は、バグのパッチ作成をお勧めします。以下のステップに従ってください。

  1. 上記の修正するバグを見つけるを読み、Trac で修正するバグを見つけます。
  2. 登録（日本語）したユーザー名とパスワードを使ってWordPress Subversion (SVN) レポジトリ に接続します。SVN を使ったことがない場合は、Subversion の使い方/en を読んでください。すべてのパッチは SVN レポジトリの最新コードに対して当てられるべきです。
  3. WordPress コアファイルを編集してバグを修正する方法を探します。仕上げる前に、wp-hackers メーリングリストで、提案したい解決方法を話し合った方が良いかもしれません。
  4. バグが直っているか、WordPress の他の部分に悪影響を与えていないかを検証するため、修正のテストを行います。
  5. 修正を含むパッチファイルを作成します。基本的にはこれは SVN の元ファイルと修正部分の diff です。詳しくは How to Patch WordPress by Owen Winkler をご覧ください。また、Linux/Mac コマンドラインユーザー向けには、Mark Jaquith's Toolbox が、Windows Tortoise SVN ユーザー向けには Westi のブログ上に説明があります。
  6. このパッチファイルを Trac の Attach file ボタンを使ってアップロードし、has-patch というキーワードを追加します。例えばパッチのテストが必要な場合は、needs-testing など、その他の Trac キーワード（下記）も必要に応じて加えましょう。

Trac キーワード

Trac には、よく使われる定義済みのキーワードが複数あります。このうち一部は Trac Reports で検索できます。

reporter-feedback（要報告者フィードバック）
報告者からのフィードバックが必要。同様の問題が起きている人からの質問に対する反応がない限り先に進めない状態。
has-patch（パッチあり）
チケットの解決策がパッチとしてアップロードされていて、レビューまたはコミット待ちの状態。
needs-testing（要テスト）
解決策のテストが必要。
2nd-opinion（要意見）
問題または解決策に関する第三者の意見が必要。
dev-feedback（要開発者フィードバック）
開発者からのフィードバックが必要（あまり使われないキーワード）
tested（テスト済み）
パッチがテスト済み。このキーワードを追加する場合は、パッチのファイル名・テスト実施の状況・テストを行った WordPress のバージョンをコメントに記入すること（公式リリースバージョンでない場合は、SVN リビジョン番号も含める）。
commit（コミット可）
パッチが開発コミュニティで信頼されているメンバーによってレビューおよびテストされ、WordPress コアファイルに追加できる状態。
needs-patch（要パッチ）
チケットのレビュー後、解決が望ましいと判断され、特にパッチが必要とマークされた状態。または投稿されたパッチがうまく動作せず、やり直しが必要な状態。
needs-unit-tests（要ユニットテスト）
チケットのレビュー後、解決が望ましいと判断され、コミットの前に機能や既存のパッチのユニットテストを行いたいと開発者が考えている状態。変更を行うことで他の問題が発生するリスクが高い場合に使われる。
needs-doc（要ドキュメンテーション）
コードのインラインドキュメンテーションが必要。個別ファイル用のプレースホルダー、またはコミットの前にドキュメンテーションが必要な新規機能のパッチを含むチケット。

バグの解決プロセス

Trac のチケットはまず open 状態からスタートし、（うまくいけば）最終的には closed になります。チケットがクローズされる場合、以下のいずれかになります。

  • バグがすでに他で報告済みの場合、たいていは duplicate としてクローズされます。
  • バグが最新の Subversion コード（テスト環境でない場合はこのコードをお使いではないでしょう）中ですでに修正済みの場合、fixed としてクローズされます。
  • 報告したバグが実際にはバグではなく意図された動作の場合、invalid としてクローズされます。
  • 他の人が説明した状況を再現できない場合、worksforme としてクローズされます。
  • バグではなく開発者がコアには入れるつもりがない機能の要望だった場合、wontfix としてクローズされます。

報告する前に、バグがこれらに当てはまらないことを検証してください。

注

  • バグの処理には協力が必要な場合があります。問題を解決するために開発者への協力をする心づもりをしておいてください。
  • 報告した問題が "Not a bug（バグではない）" や "Won't fix（修正しない）" という解決方法に落ち着いたとしても、気を悪くしないでください。あなたにとってバグと思われることは、そういう「機能」かもしれないということは十分あり得ます。これらの解決方法は単に「現在は修正するつもりはない」ということですので、将来優先的に直される可能性もあります。
  • WordPress の開発へのご協力ありがとうございます！

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

「http://wpdocs.osdn.jp/wiki/index.php?title=バグの報告&oldid=11323」から取得