The java.net site offers a utility called the Issue Tracker, that helps us manage all issues (bugs, feature requests, enhancements, and etc). You could use it to report bugs and suggest new features. Some issues are fixed quickly, others take a long time to get over with. Please be patient if your issue is not acted upon quickly. The great thing about the Issue Tracker is that reports do not get lost.

View existing entries

You can either:

• Look through all existing issues
• View all issues for a given milestone:
  1.1
  1.2
  1.3
  1.4
  
• Search their summaries:
• Jump directly to an issue:

What the Issue fields mean

The Component/Subcomponent fields identify an area within the project that this issue is associated with. These currently include:

• www for all issues related to the website
• development for all issues concerning the code

The severity of various issues is represented by 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 -- too embarrassing for a 1.0 release).
• 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.

Issue type:

• Defect is a problem with an existing feature that is either not developed to spec or does not work as designed. These are often referred to as bugs.
• Enhancement is an improvement to an existing feature.
• Feature is an addition to the software to add a piece of functionality that does not yet exist.
• Task is an activity to be done on behalf or in support of a feature or enhancement. Tasks do not typically require direct changes to the code base.
• Patch is a special kind of issue, a section of code to be applied or attached to existing software, often to fix a defect.

File an issue

We use the “Buddy System” for filing issues. Before filing a new issue, please:

• Re-read the documentation (especially the FAQ).
• Look through existing issues to see if this bug has already been reported.
• Find someone else who agrees this is a bug. Post to the dev mailing list, 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!

And so, with further ado, we give you (drumroll…) the SIP Communicator Issue Tracker.

Again, remember that to add or modify issues, you need to be logged in with the Observer role in the SIP Communicator project.

This document has been strongly influenced by Subversion’s “Issue Tracker” section