Description and Comment Headers
Issue descriptions are files identified when the
subissue:type property is set to issue. These files
contain headers describing bits of information about the issue,
followed by a complete description of the problem.
The headers function similarly to the headers found in email, and
are based off of ideas from the Debian Bug
Tracking System. The headers' names are always case sensitive
and must be spelled exactly as specified here; header values are
not case sensitive, but should be treated as such for asthetic
All of these headers, by default, are indexed and searchable by the
web-based interface. If you want to add and use custom headers, you
are free to do so, but they must be added to the Subissue Configuration before they will
be treated specially. You may also remove any of the headers that are
not "Required" if they are not applicable to your project or
Any headers not in the following list (and that you have not added
to your configuration) will be ignored by the web-based interface, but
will instead appear verbatim in the description of the issue.
||A short, to-the-point, one-line summary of the issue. When people
browse the list of issues in the web-based interface, this is what
they will see.
||One of "Unconfirmed", "New", "Started", "Reopened", "Resolved",
"Verified", or "Closed".
||The component or sub-project against which the issue or bug has
been filed. This can be any value; if you wish to restrict the set of
possible values, enter names of components in the Subissue Configuration.
||On a scale of 1 to 5, the priority of the issue. Developers
should devote immediate attention to Priority 1 issues, and 5 is the
One of the following values, in descending order of severity:
- Blocks other developers from testing or developing the project.
This is the worst possible severity, and should correspond to Priority
- Causes a crash, freeze, or severe memory leak, or casuse loss of
- Major loss of function; a blatant but non-critical bug.
- Just a normal bug.
- Rare or minor bug; a workaround is easily apparent.
- Cosmetic error or typo.
- Feature or enhancement request.
||One of the following values:
- Work on the issue is complete; a patch has been tested and committed.
- The problem described is not a bug, or is not an issue relating to
the specified project or component.
- The problem described will never be fixed, for whatever
- The issue will not be fixed until a later version or milestone, at
which time it will be reopened.
- The issue will probably not be fixed until later, but it might be,
in which case it will be reopened.
- The issue is a duplicate of another issue, and the "Duplicate:"
header has been set.
- The problem reported could not be reproduced, so attempts to debug
and fix it have failed. The issue will be reopened if a better
formula to reproduce the problem can be created.
||One of the following values, often related to the
- The issue describes a bug in or a problem with the functionality
an existing feature; part or all of the feature does not work as
expected or designed.
- The issue describes an enhancement request to an existing
- The issue describes a request for a new feature. These issues
usually have the lowest priority.
- The issue describes a general task to be performed.
||A space-separated list of keywords to help further categorize the
type or scope of the issue. Keywords can be defined in the Subissue Configuration.
||A URL that links to further information about the issue. Since
Subversion allows access to repositories over the web, the URL can be
relative to the issue's directory, or it may be an absolute URL to a
resource on another server. If you create attachments or patches to
go along with the issue, the relative path to the attachment or patch
should be specified here.
||A milestone by which work on this issue should be completed: for
example, "1.1-alpha". Milestones are defined in the Subissue Configuration.
||When work on an issue is initiated (whenever the Status
header is set to "Started"), set this header to the username and email
address of the person doing the work. For example, "username
||If the issue or bug occurs only on a specific platform (machine
architecture, such as "i386"), set this header to the name of the
||If the issue or bug occurs only on a specific operating system,
set this header to the name of the OS.
||Should be specified as the username of the person comitting the
issue when convenient, but this information can be recovered more
securely directly from the Subversion repository. The web-based
interface will automatically set this header to the proper value.
||Should be specified as the date in which the issue was created,
but this information can be recovered more securely directly from the
Subversion repository. The web-based interface will automatically set
this header to the proper value.
Issue comments are files identified when the
subissue:type property is set to comment. These
files contain headers describing bits of information about the issue,
followed by the text of the comment.
The headers available for use in comments are a subset of those
available for issue descriptions. The following is a list of the
headers that are treated specially by the web-based interface. All
headers not in the following list will be ignored, and will appear
verbatim in the text of the comment. The list can be modified in the