Users reporting bugs don’t always know what components to set.  http://docs.python.org/devguide/triaging#components should explain them.

This are the current components in random order and a possible description:
"""
The following components should be selected if the issue apply to:
Build
  the build process
Demos and Tools
  the scripts in Tools/ and Tools/demo/
2to3 (2.x to 3.0 conversion tool)
  the 2to3 conversion tool and Lib/2to3/
Extension Modules
  C modules in Modules/
IDLE
  IDLE and Lib/idlelib/
Installation
  the installation process
Interpreter Core
  the interpreter core, built-in objects in Objects/, the Python/, Grammar/ and Parser/ dirs
Library (Lib)
  Python modules in Lib/
Regular Expressions
  regular expressions, and the Lib/re.py and Modules/_sre.c modules
Tests
  the tests in Lib/test/, the unittest and doctest frameworks in Lib/unittest/, Lib/doctest.py
Tkinter
  Tkinter an Lib/tkinter
Unicode
  Unicode, codecs, str vs bytes, Objects/unicodeobject.c
Windows
  the Windows operating system
XML
  XML and Lib/xml/
Macintosh
  the Macintosh operating system
Documentation
  the documentation in Doc/
Benchmarks
  ???
Distutils
  the distutil package in Lib/distutils/
Distutils2
  the packaging package in Lib/packaging/
Devguide
  the devguide at h.p.o/devguide
ctypes
  the ctypes package in Lib/ctypes/
"""

I'm not sure what the Benchmark component is supposed to be about (generic benchmarks? timeit/profile and friends? "performance" issues?).
If I got all the descriptions and files/dirs right I can prepare a patch for the devguide.  FWIW there was a somewhat similar issue in the meta-tracker too.

Attached a proper patch.

+2to3 (2.x to 3.0 conversion tool)
+    the 2to3 conversion tool and `Lib/lib2to3/`_
Hm, given that the tool (IOW the script) is only a few lines, I find the line a bit strange; 2to3 == Lib/lib2to3.  (See also below before you reply to that.)

Personal style thing: I don’t like putting os.sep at the end of directory paths.

+    the benchmarks in the `benchmarks`_ repo
reST protip: For sequences of characters without spaces, you can use just benchmarks_.

+Demos and Tools
+    the scripts in `Tools/`_ and `Tools/demo/`_
The files in* (they are not all scripts).  Sidenote: I think English typography would have us capitalize the definition lines.

+Devguide
+    the `devguide`_
The `Developer’s Guide`_

+Distutils
+    the distutil package in `Lib/distutils/`_
Typo: distutils*.

+Distutils2
+    the packaging package in `Lib/packaging/`_
I always call it “the packaging module”, to avoid the weird-sounding, potentially confusing “packaging package”.

+Documentation
+    the documentation in `Doc/`_
Maybe also mention that it’s the source for what’s published at docs.python.org

+Extension Modules
+    C modules in `Modules/`_
I believe some of them are under Lib.  I also don’t know whether imp for example should be Core or Extension Modules.

+IO
+    the IO, `Lib/io.py`_ and `Modules/_io/`_
Maybe “the I/O system”

+Macintosh
+    the Macintosh operating system
That’s vague.  What about “Used for bugs specific to Mac OS X”?

+Regular Expressions
+    regular expressions, and the `Lib/re.py`_ and `Modules/_sre.c`_ modules
Here again, I’m a bit startled by “and”: regular expressions == re.py and _sre.c

+Tests
+    the tests in `Lib/test/`_, the unittest and doctest frameworks in
+    `Lib/unittest/`_, `Lib/doctest.py`_

To make people able to answer “Is this Library or Tests?”, I think we could say something like this: Issues and improvements for tests and test frameworks (unittest, doctest, regrtest).

I’m not sure putting emphasis on the paths, like your patch does, is enough to explain for example the difference between Library and Extension Modules.  If I understand the components correctly, their main utility is to let people be auto-assigned/nosied, or to let people find things that interest them or that they can help with, so for example “Mac-only bug” vs. “universal bug” is a useful distinction, “Documentation” lets people with reST skill find things to work on, “written in Python” vs. “written in C” is also useful, etc.

If the above analysis seems good, then I propose to update your patch, to be fair, as you put time to do this and now I’m basically saying that no line is good :)

Attached a new patch.
I addressed most of your comments.
AFAICT there are no extension modules in Lib.  All the C modules are in Modules, and if they also have a Python "frontend", that's in Lib.  I think the point of having Extension Modules and Library is to distinguish between C modules and Python modules.

I split the "Tests" component in two different entries:
  1) about our tests, regrtest and test/support.py;
  2) unittest/doctest;
I think the "Tests" component applies to both, and for unittest/doctest it can be used together with "Library".

Listing the paths is both good for people that are submitting ("the error comes from this module"), and for people fixing it ("this component is selected, I should look in that module").

While I could question the current list of components, documenting it as it is is a good idea. Patch 2 looks pretty good to me with the following change.

Tests
    The generic unittest and doctest frameworks in `Lib/unittest`_ and
    `Lib/doctest.py`_.
    The Python interpreter tests in `Lib/test`_, the test runner in
    `Lib/test/regrtest.py`_, and the `Lib/test/support.py`_ module.

Fixed in http://hg.python.org/devguide/rev/c9dd231b0940