[gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa/bug-wranglers: index.xml

[Jeroen Roovers (jer)]

jer         11/01/23 18:43:03

  Modified:             index.xml
  Log:
  Text formatting. Wording.

Revision  Changes    Path
1.20                 xml/htdocs/proj/en/qa/bug-wranglers/index.xml

file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml?rev=1.20&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml?rev=1.20&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml?r1=1.19&r2=1.20

Index: index.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- index.xml	16 Nov 2010 15:10:55 -0000	1.19
+++ index.xml	23 Jan 2011 18:43:03 -0000	1.20
@@ -6,7 +6,7 @@
 <project>
 <name>Bug Wranglers</name>
 <longname>The Bug Wranglers Project</longname>
-<date>2010-05-26</date>
+<date>2011-01-23</date>
 <author title="Author">
 <mail link="jer" />
 </author>
@@ -18,20 +18,24 @@
 
 <longdescription>
 <p>
-The Gentoo Bug Wranglers project controls, describes the tasks to be carried out and
-goals to be achieved for everyone who wrangles bugs on Gentoo's <uri
-link="http://bugs.gentoo.org/">bug tracker</uri>.</p>
-<p>The project was erected after the de facto resignation of long time <e>Main
+The Gentoo Bug Wranglers project controls and describes the tasks to be carried
+out and goals to be achieved for everyone who wrangles bugs on Gentoo's <uri
+link="http://bugs.gentoo.org/">bug tracker</uri>.
+</p>
+<p>
+The project was set up after the de facto resignation of long time <e>Main
 Bug Wrangler</e> Jakub Moc, when it turned out we required a division of labour
-to see all bugs reassigned within an acceptable timeframe (from the moment of a
-bug report's creation to its proper assignment). For his years of relentless
-bug wrangling, this project both owes him its gratitude and earns its
-existence.</p>
-<p>In its current phase, the project now strives to get every bug assigned
-within a day, counting from the moment when enough information has been
-gathered. In the future, the project's aims are to credit developers and users
-who help out, to maintain a list of notable bug wranglers, and to gather yet
-more useful guidelines on this page.
+to get all bugs properly assigned within an acceptable timeframe (from the
+moment of a bug report's creation to its proper assignment). For his years of
+relentless bug wrangling, this project both owes him its gratitude and earns
+its existence.
+</p>
+<p>
+The project strives to get every bug assigned within a day, counting from
+the moment when enough information has been gathered. In the future, the
+project's aims are to credit developers and users who help out, to maintain a
+list of notable bug wranglers, and to gather yet more useful guidelines on this
+page.
 </p>
 </longdescription>
 
@@ -163,7 +167,8 @@
 information, depending on the type of bug report.
 </p>
 <ul>
-<li>If a bug report pertains to a specific <b>package</b>, then you enter the
+<li>
+If a bug report pertains to a specific <b>package</b>, then you enter the
 package's directory in your copy of the <uri
 link="http://sources.gentoo.org/viewcvs.py/gentoo-x86/">gentoo-x86 CVS
 repository</uri> (or perhaps the online version which should always be more or
@@ -173,14 +178,18 @@
 assign the bug to the first maintainer, and CC the other maintainer(s) and
 herd(s). If you find that <c>metadata.xml</c> lists inappropriate and/or
 confusing contact information, then make a note of that in a comment on the bug
-report and assign/CC the bug report as optimal as possible.</li>
-<li>In cases where <c>metadata.xml</c> lists a herd which Gentoo Bugzilla
+report and assign/CC the bug report as optimal as possible.
+</li>
+<li>
+In cases where <c>metadata.xml</c> lists a herd which Gentoo Bugzilla
 doesn't know about (which it will ask you to correct before it accepts changes
 to the bug report), you should consult <uri
 link="/proj/en/metastructure/herds/herds.xml">herds.xml</uri> to figure out the
-appropriate e-mail alias for that herd.</li>
-<li>When a bug report calls attention to <b>multiple packages</b>, then things
-become slightly more complicated. When the listed packages do not belong to the
+appropriate e-mail alias for that herd.
+</li>
+<li>
+When a bug report calls attention to <b>multiple packages</b>, then things
+get slightly more complicated. When the listed packages do not belong to the
 same maintainer or team, for instance when a library upgrade causes several
 packages to fail to emerge or run, then you should ask the bug reporter to file
 separate bugs assigned to each set of packages' maintainer(s), and make those
@@ -188,32 +197,43 @@
 bug</b> (denoted by the <c>Tracker</c> keyword. Bug reports with many
 maintainers CC'd are known to bog down and never get resolved. Of course, you
 should only create a tracker bug when the bug is confirmed and the solution is
-clear.</li>
-<li>Bug reports that concern <b>eclasses</b> should be assigned to the eclass
+clear.
+</li>
+<li>
+Bug reports that concern <b>eclasses</b> should be assigned to the eclass
 maintainer. To figure out who maintains an eclass, browse to the
 <uri link="http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass">gentoo-x86/eclass</uri>
 directory, open the file and read who maintains the eclass at the top of the
 file. When an eclass file does not list maintainers, the bug report should
 note this omission and the last committer to that file should be made the
-report's assignee.</li>
-<li>A <b>keyword request</b> should be assigned to the package's maintainer and
+report's assignee.
+</li>
+<li>
+A <b>keyword request</b> should be assigned to the package's maintainer and
 CC'd to the appropriate arch team(s). The report's <c>Keywords</c> field should
-contain the <c>KEYWORDREQ</c> keyword.</li>
-<li>A <b>stabilisation request</b> should be handled by the package's maintainer, so
+contain the <c>KEYWORDREQ</c> keyword.
+</li>
+<li>
+A <b>stabilisation request</b> should be handled by the package's maintainer, so
 you should not CC arch teams in your role as bug wrangler, nor set the
 <c>STABLEREQ</c> keyword in the <c>Keywords</c> field. Unless the package is
 maintainer-needed, then you should add arches and set the Keyword field if the
-bug makes sense.</li>
-<li>Bug reports that concern <b>profiles</b> should be assigned to
+bug makes sense.
+</li>
+<li>
+Bug reports that concern <b>profiles</b> should be assigned to
 <uri link="mailto:qa@g.o">qa@g.o</uri> with
 <uri link="mailto:release@g.o">release@g.o</uri> CC'd. Exceptions
 are profiles that are obviously maintained by some herd, like hardened, selinux,
-prefix, etc. Those get assigned to the maintaining herd.</li>
-<li>Bug reports that relate to issues other than the portage tree, like
+prefix, etc. Those get assigned to the maintaining herd.
+</li>
+<li>
+Bug reports that relate to issues other than the portage tree, like
 problems with Gentoo's bugzilla, Gentoo infrastructure, mirrors or staffing
 matters (devrel, userrel and so on) are usually easier to assign. The
 <c>Product</c> and <c>Component</c> fields of each bug should help you
-(re)assign these reports appropriately.</li>
+(re)assign these reports appropriately.
+</li>
 </ul>
 </body>
 </section>