| 1 |
jer 08/09/10 05:07:46 |
| 2 |
|
| 3 |
Modified: index.xml |
| 4 |
Log: |
| 5 |
Add acquisition section. Improvements here and there. |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.9 xml/htdocs/proj/en/qa/bug-wranglers/index.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml?rev=1.9&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml?rev=1.9&content-type=text/plain |
| 12 |
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml?r1=1.8&r2=1.9 |
| 13 |
|
| 14 |
Index: index.xml |
| 15 |
=================================================================== |
| 16 |
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml,v |
| 17 |
retrieving revision 1.8 |
| 18 |
retrieving revision 1.9 |
| 19 |
diff -u -r1.8 -r1.9 |
| 20 |
--- index.xml 8 Sep 2008 16:24:08 -0000 1.8 |
| 21 |
+++ index.xml 10 Sep 2008 05:07:46 -0000 1.9 |
| 22 |
@@ -6,7 +6,7 @@ |
| 23 |
<project> |
| 24 |
<name>Bug Wranglers</name> |
| 25 |
<longname>The Bug Wranglers Project</longname> |
| 26 |
-<date>2008-09-08</date> |
| 27 |
+<date>2008-09-10</date> |
| 28 |
<author title="Author"> |
| 29 |
<mail link="jer" /> |
| 30 |
</author> |
| 31 |
@@ -70,8 +70,8 @@ |
| 32 |
error or faulty output, and concise steps explaining how to reproduce the |
| 33 |
issue. It is customary to only assign a bug report once these requirements have |
| 34 |
been fulfilled. If the reporter hasn't fulfilled these requirements, the bug |
| 35 |
-should be ASSIGNED to bug-wranglers, and a full build log should be requested |
| 36 |
-from the reporter.</li> |
| 37 |
+should be marked <c>ASSIGNED</c> to bug-wranglers, and a full build log should |
| 38 |
+be requested from the reporter.</li> |
| 39 |
<li>Bug reports that <b>include patches</b> or other solutions accompanying |
| 40 |
the actual bug description can usually be assigned directly to the maintainers.</li> |
| 41 |
<li>The <c>Summary</c> uniquely identifies the bug that is being reported. As |
| 42 |
@@ -90,6 +90,50 @@ |
| 43 |
</section> |
| 44 |
|
| 45 |
<section> |
| 46 |
+<title>Acquiring More Information (and when not to)</title> |
| 47 |
+<body> |
| 48 |
+<p>Bug reports can quickly get messy from comments and attachments that may or |
| 49 |
+may not be appropriate to the bug being reported. Handing over such bug reports |
| 50 |
+to the proper assignees is not much fun, and you cannot delete comments or |
| 51 |
+attachments that aren't any use (although you can mark the latter as obsolete |
| 52 |
+if need be). Since you cannot filter out the information you ultimately hand |
| 53 |
+over to the assignee, you will have to make sure you don't just ask for the |
| 54 |
+right information, but ask it in the best possible way. Sometimes, it is |
| 55 |
+necessary to request that no more information is added. In general, be gentle |
| 56 |
+in your verbal assessment of a bug report. Even if you are quite certain that |
| 57 |
+it's going to be resolved as <c>INVALID</c>, you should treat the reporter |
| 58 |
+<b>courteously</b>.</p> |
| 59 |
+<ul> |
| 60 |
+<li>If you find that a reported problem arose because <b>the reporter lacks |
| 61 |
+certain skills</b> or knowledge, then provide the so-called 'obvious' solution |
| 62 |
+to the problem and suggest that he might try that. It is unnecessary to explain |
| 63 |
+that you consider the reported problem not to be a bug. Just resolve the bug |
| 64 |
+with a <c>TEST-REQUEST</c> (instead of as <c>INVALID</c>) and suggest that the |
| 65 |
+reporter tests the solution you provide, and that he reopens the bug only when |
| 66 |
+that doesn't solve the problem.</li> |
| 67 |
+<li>Assume that the reporter can help but may not know how, without either |
| 68 |
+suggesting he may not know how or assuming he does know how. In practice, that |
| 69 |
+means you provide the <b>commands that produce the information you require</b>. |
| 70 |
+Do so even if the means to that end seem trivial, like asking for `emerge |
| 71 |
+--info' or `emerge -vp cat/pkg'.</li> |
| 72 |
+<li>Do not assume that the reporter ought to know <b>how to report bugs</b>. An |
| 73 |
+omitted `emerge --info' does not call for a public flogging, it simply calls |
| 74 |
+for the missing `emerge --info'. Even experienced reporters make mistakes, so |
| 75 |
+simply request the information, mark the bug as <c>ASSIGNED</c> and wait for |
| 76 |
+the information you requested.</li> |
| 77 |
+<li>Bug reports should be concise, as all too quickly they bog down and can |
| 78 |
+be best understood after reading, say, nothing but comment #1, #2 and #7, |
| 79 |
+ignoring all 40 intermediate and later comments which are the me-toos and |
| 80 |
+not-mes (including lots of `emerge --info' and/or hardware collection lists |
| 81 |
+that may or may not be relevant). <b>When enough information has been |
| 82 |
+presented</b> to 'make a case', it's appropriate to say so.</li> |
| 83 |
+<li>Some bugs make your blood boil. Ignore them and let someone else handle |
| 84 |
+them.</li> |
| 85 |
+</ul> |
| 86 |
+</body> |
| 87 |
+</section> |
| 88 |
+ |
| 89 |
+<section> |
| 90 |
<title>Assigning Bug Reports</title> |
| 91 |
<body> |
| 92 |
<p> |
| 93 |
@@ -103,7 +147,7 @@ |
| 94 |
repository</uri> (or perhaps the online version which should always be more or |
| 95 |
less up to date) and read the <c>metadata.xml</c> file you find there. When |
| 96 |
<c>metadata.xml</c> lists a single maintainer or herd, then you assign the bug |
| 97 |
-to that maintainer or herd. When the file lists multiple entries, then you |
| 98 |
+to that maintainer or herd. When the file lists multiple entries, then you |
| 99 |
assign the bug to the first maintainer, and CC the other maintainer(s) and |
| 100 |
herd(s). If you find that <c>metadata.xml</c> lists inappropriate and/or |
| 101 |
confusing contact information, then make a note of that in a comment on the bug |
| 102 |
@@ -127,7 +171,7 @@ |
| 103 |
maintainer. To figure out who maintains an eclass, browse to the |
| 104 |
<uri link="http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass">gentoo-x86/eclass</uri> |
| 105 |
directory, open the file and read who maintains the eclass at the top of the |
| 106 |
-file. When an eclass file does not list maintainers, the bug report should |
| 107 |
+file. When an eclass file does not list maintainers, the bug report should |
| 108 |
note this omission and the last committer to that file should be made the |
| 109 |
report's assignee.</li> |
| 110 |
<li>A <b>keyword request</b> should be assigned to the package's maintainer and |
| 111 |
@@ -157,10 +201,18 @@ |
| 112 |
appreciate it if, in doing so, you follow the rules layed out above. |
| 113 |
</p> |
| 114 |
<p> |
| 115 |
-Users are encouraged to assist in wrangling bugs as well. Even without bugzilla |
| 116 |
+Users are encouraged to assist in wrangling bugs as well. Even without bugzilla |
| 117 |
privileges you can help by reproducing bugs and posting additional information |
| 118 |
where possible. |
| 119 |
</p> |
| 120 |
+<p>The best approach to bug wrangling is to really <b>get involved</b> with |
| 121 |
+individual bug reports. Do not wrangle bugs if all you want is to shorten the |
| 122 |
+list down. Just CC yourself when you are not quite sure you assigned a bug |
| 123 |
+report properly or when you requested information. You can always un-CC when |
| 124 |
+you find the bug has landed in the right hands.</p> |
| 125 |
+<p>The bug wranglers are now many, which means that you don't have to do |
| 126 |
+<b>everything</b>. It also means that you can keep check on the bug reports you |
| 127 |
+responded to and help guide them to satisfactory solutions.</p> |
| 128 |
</body> |
| 129 |
</section> |
| 130 |
</extrachapter> |
Archives