From WhyNotWiki

Issue tracking  edit   (Category  edit)

Contents 1 Reporting bugs 1.1 1.2 [Reproducibility (category)] 2 Issue tracking policies / triage (scope: software) 2.1 Resolving bugs 2.1.1 Resolving bugs as DUPLICATE 2.1.2 Resolving bugs as WORKSFORME 2.1.3 Resolving bugs as INVALID 2.1.4 Resolving bugs as FIXED 2.1.5 Resolving bugs as WONTFIX 2.2 Changing the bug information fields 2.2.1 Summary 2.2.2 Priority/Target Milestone 2.3 Status and Resolution 2.4 Ticket Type 2.5 Ticket Description 2.6 Keywords 2.7 Miscellaneous 2.8 Rails Trac Keywords 3 Subversion project 3.1 Issue Tracker Guidelines 3.2 What the Issue Fields Mean 4 Issue tracking software 4.1 Instances: Implemented in Ruby 4.1.1 Lighthouse 4.2 Instances 4.2.1 Bugzilla 4.2.2 Trac 4.2.3 RT: Request Tracker 4.2.4 Help Desk Reloaded 4.3 Desired features 5 5.1 Idea: attaching a comment to a particular class/module/method 5.2 Benefits 6 Article metadata

[edit] Reporting bugs

How to report bugs effectively

From the "Reporting bugs" section of an e-mail sent out by Bram Moolenaar to the vim-announce list:

Send them to <bugs@vim.org>. Please describe the problem precisely. All the time spent on answering mail is subtracted from the time that is spent on improving Vim! Always give a reproducible example and try to find out which settings or other things influence the appearance of the bug. Try starting without your own vimrc file: "vim -u NONE". Try different machines if possible. See ":help bugs" in Vim. Send me a patch if you can!

If something needs discussing with other developers, send a message to the vim-dev mailing list. You need to subscribe first.

[reproducibility (category)]

[edit]

• How to report bugs effectively

[edit] [Reproducibility (category)]

http://trac.example.com/admin/general/basic

Oops… Trac detected an internal error:

If you think this really should work and you can reproduce it, you should consider reporting this problem to the Trac team.

Go to http://trac.edgewall.org/ and create a new ticket where you describe the problem, how to reproduce it. Don't forget to include the Python traceback found below.

TracGuide — The Trac User and Administration Guide Python Traceback

Traceback (most recent call last):

...
IOError: [Errno 13] Permission denied: '/var/trac/.../conf/trac.ini'

[edit] Issue tracking policies / triage (scope: software)

What to do and what not to do in Bugzilla (http://www.mozilla.org/quality/help/bugzilla-privilege-guide.html). Retrieved on 2007-04-04 17:05.

[edit] Resolving bugs

Some general rules:

• When you resolve a bug, CC yourself so that you are informed when new facts come up.
• The conditions for not resolving a bug always overrule the conditions for resolving a bug.
• When in doubt about resolving a bug, leave it alone!

[edit] Resolving bugs as DUPLICATE

See this guide for screening DUPLICATE bugs. In general newer bugs should be marked as DUPLICATEs of older bugs, except when the newer bug contains more information (bug description clearer, patch already attached, lots of people already CC'ed, etc.).

[edit] Resolving bugs as WORKSFORME

You can resolve a bug as WORKSFORME (WFM) if it can't be reproduced on the reported hardware/OS.

You should not resolve a bug as WFM if:

• the bug reporter uses a different hardware/operating system (e.g. bug appears on Linux and you can't reproduce it on Windows).
• the bug has been reproduced by some people but can't be reproduced by other people.

In general you can resolve a bug as WFM if:

• three or more people with a similar/the same setup can't reproduce the bug and the bug is only seen by the bug reporter. In this case you shouldn't just mark it WFM instantly, but ask the reporter for more details first. When marking it WFM you should tell the bug reporter that he should reopen the bug if he can still see it with a recent build.
• the build the bug is reported against is more than one stable release old and the bug can't be reproduced with a current build.
• the bug reporter has not responded to questions for one month and the bug can't be reproduced with a current build.
• the bug reporter reports that he can no longer see the bug and no other people report that they are still seeing the bug.

[edit] Resolving bugs as INVALID

You should resolve a bug as INVALID, if the issue described in the bug is clearly not a Mozilla bug or if the issue is intended behaviour. The exception are bugs in other software which we have to work around. Bugs covering this exception should not be INVALIDated by anyone other than the module owner or module peer. Reports of problems with websites that result from bad coding or use of proprietary technology should also not be INVALIDated, but instead moved to the Tech Evangelism product. Resolving bugs as FIXED

Resolve a bug as FIXED if the bug has been fixed by a checkin into the Mozilla CVS code repository. Bugs which can no longer be reproduced should be marked WORKSFORME instead of FIXED if they can't be linked to a single checkin. Resolving bugs as WONTFIX

Bugs should not be marked WONTFIX by the normal bug triager. The decision to mark a bug WONTFIX is reserved for module owners or module peers. Verifying bugs

You should verify a bug if it has been proven that the resolution of the bug was correct. When verifying a bug, you should remember the following:

• Verifying DUPLICATEs is the easiest task, so start with that. Note that in general it's impossible to verify a DUPLICATE until the original has been resolved.
• Verifying WONTFIX or INVALID bugs is relatively easy if a developer or a trusted QA person has WONTFIXed or INVALIDated them. Bugs that were INVALIDated or WONTFIXed by someone else must be verified by a module owner or module peer or someone who has been explicitly told by a module owner or module peer that they are able to do so for that module.
• Before verifying FIXED bugs, make sure that you can verify them on every hardware/OS they were reported on. If that's impossible, try to cooperate with multiple people to verify the bug.
• There are no clear rules for verifying WORKSFORME. In general you should make sure that the bug has been resolved for a few months and no complaints about the resolution have come up.

[edit] Resolving bugs as FIXED

Resolve a bug as FIXED if the bug has been fixed by a checkin into the Mozilla CVS code repository. Bugs which can no longer be reproduced should be marked WORKSFORME instead of FIXED if they can't be linked to a single checkin.

[edit] Resolving bugs as WONTFIX

Bugs should not be marked WONTFIX by the normal bug triager. The decision to mark a bug WONTFIX is reserved for module owners or module peers.

[edit] Changing the bug information fields

[edit] Summary

You should change the summary if the current one is unclear or does not correctly describe the issue covered by the bug.

You should not change the summary in order to morph the bug to describe a different issue. In this case the bug should be resolved and another bug should be opened.

[edit] Priority/Target Milestone

As stated in the Bugzilla Etiquette you must not change the Target Milestone and Priority fields. These fields are reserved for the developers. Bugs with Target Milestones in the past are not excepted.

TracTicketTriage - The Trac Project (http://trac.edgewall.org/wiki/TracTicketTriage). Retrieved on 2007-04-04 17:05.

[edit] Status and Resolution

• fixed
  • is used when the resolution of the ticket can be linked to some change in the repository, a code change, a primary documentation fix, a contribution script added, etc. For ticket type task, fixed is used even if there was no trackable change in the repository/documentation.
• worksforme
  • the problem reported was not really a problem; the requested feature is already implemented or can be obtained in a different way
• wontfix
  • the problem reported is not really Trac's problem; the requested feature won't be implemented because we don't think it fits in the scope of the core of Trac, or the feature is implemented as a plugin.
• invalid
  • the ticket was a test ticket, intended for another Trac, etc.
• duplicate
  • there's already another ticket about the same issue
    • If marking as duplicate, include referring ticket #s in both duplicate and duplicated tickets.
      • In duplicate ticket: This ticket is duplicate of #1234
      • In original request: #2345 has been marked as duplicate of this ticket
    • We usually let open the ticket which contains the most up-to-the-point discussion about the issue, the one which contains an appropriate patch, or other than that, the oldest ticket.

And also, don't close or reopen a ticket without a reason.

[edit] Ticket Type

When the ticket is neither about something that requires a modification to the documentation or the code, use the task type.

[edit] Ticket Description

Only administrators can edit ticket descriptions. They are only edited to fix formatting errors, not the actual content. Occasionally, we may also add editorial notes, in order to not spread misleading information, e.g. #4297 or to summarize the current status of a long running issue, e.g. #4132 or #2611. In all cases, it should be quite clear from the formatting what's coming from the original author and what has been annotated afterwards.

[edit] Keywords

# General indications - influencing the ticket workflow

    * needinfo - waiting on information from the reporter
    * verify - the ticket looks to be a valid bug report, but it would be worth that someone actually reproduces it, mainly because the person doing the triage can't reproduce it himself for some reason (different platform / browser / database, etc.)
    * consider - interesting tickets, mainly for enhancements requests, that are worth to consider in the scope of a given milestone, but for which there's no commitment yet
    * tobedeleted - "noise" tickets that could eventually be safely deleted one day
    * helpwanted - tickets which are looking for contributors
    * review - peer review requested
    * documentation - things that need to be better documented
    * patch - same as review keyword, but when a patch is created by a third party
    * refactoring - indicates a refactoring step (e.g. patch) which changes structure but not functionality 

# Related to work done in branches:
setuptools, workflow (see WorkFlow), permissions (see PermissionPolicy), xref (see TracCrossReferences), tracobject (see GenericTrac)
# Related to some technology/APIs used: datetime, unicode, genshi, wsgi
# wannabee components:
attachment, authz, config, custom fields, diff, syntax highlighting, milestone, mimeview, plugin, query, session
# Related to backends and other 3rd party software

    * DatabaseBackends: mysql, postgresql, pysqlite
    * VersioningSystemBackends: svn (svn12, svn13, svn14), svk, mercurial
    * Python compatibility issues: python21, python22, python25
    * Other Python packages used: docutils, enscript, silvercity 

# Platform specific issues: windows, solaris, macosx (TODO: there are some Macintosh OS X to fix)
# Presentation issues

    * layout
    * css, javascript, xhtml
    * Browser specific: opera, iexplorer, iexplorer7, firefox, safari 

# Other kinds of grouping

    * crash - There's a segmentation fault or other serious OS level error implied.
    * memory - Out of memory condition, most probably involving memory leaks.
    * security - Security issues with Trac 

[edit] Miscellaneous

• Avoid closing tickets without a comment of the reporter [person who reported the ticket]
  • This is especially true if the reporter is an active contributor
• core developers have final authority to close tickets

[edit] Rails Trac Keywords

Riding Rails: All about Rails Trac keywords (http://weblog.rubyonrails.org/2006/6/2/all-about-rails-trac-keywords). Retrieved on 2007-04-05 10:35.

Keywords in the Rails Trac get used in two ways.

A tagging system (anyone can use)

The first is a standard tagging system, where users tag tickets with whatever keywords they think describe the topic of the ticket. To give you an idea of what people use this type of tag for, here are the 25 most commonly used ones:

postgresql, performance, ajax, test, routes, sqlserver, activerecord, mysql, rake, documentation, form, prototype, generator, fixtures, error, helper, migration, patch, scaffold, webrick, oracle, adapter, session, has_many, tested, inflector, date.

Using keywords as tags is fine, but by no means required. It may make it easier for someone to find your ticket if they encounter a similar issue, but it's not a big deal if you don't use any tags at all.

To help manage how tickets are processed (for use by core team only)

The second way keywords are used is to help manage how tickets are processed. As of this writing there are 20 standard reports in the Rails Trac, and nine of them filter tickets based on specific keywords. A couple of the reports are only used during a push towards a release. One is being used for managing documentation updates. And six are about the life-cycle and categorization of patches. Those six are the ones that are interesting to us here.

A patch is just a ticket that has .diff file attached that contains a bug-fix or enhancement of some sort. The summary line for patch tickets should always start with the text [PATCH]. You don't need to use a patch keyword - it's redundant and no one pays attention to it. There are just five keywords that are used to manage patches during regular (non-push) development:

verified, unverified, needy, risky, tiny

Here's how to use these keywords on your patch: Don't. You should not use any of these keywords when creating a patch ticket. They are used by the core team to indicate the processing state of a patch, and if you add the keywords yourself it can confuse matters and might make it harder for someone to sort out what to do with the patch.

[...] Here's a summary of what the keywords are used for.

• Verified and unverified indicate whether someone from the core team (or designated helper) has checked out the patch to see if it operates as claimed, tests pass, etc.
• Needy, risky, and tiny indicate the patch's potential impact to stability and if extra work might be involved in getting it working.

Full explanations can be found on the report pages in Trac. Look at reports 3, 4, 11, 12, 16 and 17, if you really want to know.

[edit] Subversion project

http://subversion.tigris.org/project_issues.html

[edit] Issue Tracker Guidelines

We use the "Buddy System" for filing issues.

Before filing a new issue, please:

• Re-read the documentation (especially the FAQ and the online Subversion book).

• Look through all existing issues, or search their summaries to see if this bug has already been reported.

• Find someone else who agrees this is a bug.

Post to the users@subversion.tigris.org mailing list (or to dev@subversion.tigris.org if you're already pretty sure it's a bug), or chat in IRC, regarding the bug or feature request you were about to file. People there will ask you questions, try to reproduce the problem, advise you if there's any past history of similar problems, and in general help you decide whether a new issue is warranted. If it is, they can also help you get the bug report into a useful form. See here for how to write a useful bug report.

If you do file an issue, remember to include a link to the mailing list message(s) or IRC conversation where you discussed the problem. Not only does this provide important context for anyone reading the issue, it also confirms that the issue has passed the basic buddy test: you found someone else who agrees it's a problem. Issues that haven't been through the "buddy system" may be summarily closed. We're sorry to do this, but statistically, most unbuddied filings turn out to be bogus, and the issue tracker is not a convenient place to separate the good reports from the bad.

We depend on the mailing list and IRC channel as a first level of filtering for our bug tracker. Without this filtering, the tracker would be full of duplicate issues, non-issues, and unreproducible issues. Please help us keep the bug database clean, by always finding a buddy before you file!

When mailing the list with a concern, make sure that your e-mail describes your bug or enhancement fully. Provide details about the versions of the relevant software (Subversion, Apache, neon, etc.) that you are using, about your operating system, and about any other thing that might seem pertinent to the issue. If you can provide a script which consistently reproduces a problem, that can be incredibly helpful to those evaluating and/or working on your issue.

...

[edit] What the Issue Fields Mean

When an issue is first filed, it automatically goes in the "---" target milestone, which indicates that the issue has not yet been processed. A developer will examine it and maybe talk to other developers, then estimate the bug's severity, the effort required to fix it, and schedule it in a numbered milestone, for example 1.1. (Or they may put it the unscheduled or nonblocking milestone, if they consider it tolerable for all currently planned releases.)

An issue filed in unscheduled might still get fixed soon, if some committer decides they want it done. Putting it in unscheduled merely means it hasn't been scheduled for any particular release yet. The nonblocking milestone, on the other hand, means that we do not anticipate ever scheduling the issue for a particular release. This also does not mean the issue will never be fixed; it merely means that we don't plan to block any release on it.

Severity is represented in the Priority field. Here is how priority numbers map to severity:

• P1: Prevents work from getting done, causes data loss, or BFI ("Bad First Impression").
• P2: Workaround required to get stuff done.
• P3: Like P2, but rarely encountered in normal usage.
• P4: Developer concern only, API stability or cleanliness issue.
• P5: Nice to fix, but in a pinch we could live with it.

Effort Required is represented in the Status Whiteboard with an "e number", which is the average of the most optimistic and most pessimistic projections for number of engineer/days needed to fix the bug. The e number always comes first, so we can sort on the field, but we include the actual spread after it, so we know when we're dealing with a wide range. For example "e2.5 (2 / 3)" is not quite the same as "e2.5 (1 / 4)"!

[edit] Issue tracking software

Issue tracking software edit

[edit] Article metadata

Aliases: Bug tracking