Filing a New Ticket

Before you can file a ticket, you first need a tracker account; please use the contact form to request one.

When filing a ticket, please make sure to include as much information as possible, in particular when reporting a problem. See the page on reporting problems for what’s particular helpful.

It’s crucial to select the right category:

• A problem is something not working as expected, or looking different than it should.
• A feature request is a enhancement you would like to see (but not a problem in existing functionality.)
• A patch is a source code change you’d like to see applied to the specified component/version. Select the appropriate component (if in doubt, use Bro) and the version the patch applies to, and attach the patch itself to the ticket. See the page on our contributions for more information on creating patches.

The following categories are primarily for developers:

• A task is a “to do” entry that somebody (ideally you!) is planning to work on. For a task it’s often already clear how to address the issue, and if so include that into the ticket. If you are filing a task for yourself, assign the ticket to your account.
• A merge request indicates that a git branch is ready for merging. See the page on our development process for more information.
• A fastpath ticket indicates that a change has been committed to the fastpath branch for merging. Likewise, see the page on our development process for more information.
• A missing test case is a piece of functionality that’s correcness should really be verified by the test-suite but no regression test exists yet.

When selecting a priority, please reserve high for really important stuff. In general, it’s best to avoid assigning tickets to specific persons unless you’re really sure about who’s going to work on it soon.

Ticket Work-Flow

You need to be a registered developer to change the status of an existing ticket.

When a ticket is new, it should be inspected by one of the developers rather soon and have its state changed as appropriate. If there is no immediate action to be taken, set a milestone if deemed appropiate and otherwise leave the ticket as it is. If the ticket does not appear to be relevant at all, feel free to close it. When you believe somebody particular should look at a ticket, assign it to the person (who might be yourself!). If you accept a ticket (either after it has been assigned to you, or directly), you are considered in charge of it and are responsible for making sure that it will be closed eventually. When a ticket is ready to be closed, declare it as resolved and include a reason for doing so. In particular, when you have applied a patch as requested by the filer, close the ticket. When you believe that more information is needed to address a ticket, change its status to information needed. Feel free to closed tickets in this state when they don’t see any timely response.

Useful Mark-Up

Below is some useful mark-up for writing ticket descriptions. There’s a lot of information about Trac’s mark-up language in general, and its link syntax in particular.

Examples that might be helpful:

• Inlining formatted code in text:

  The function `Hello World` prints "Hello World" in typewriter font.
  Refer to another ticket #1 or ticket:1.
  

• Adding a code block:

  def HelloWorld():
      print "Hello World"
  \}\}\}
  

• Using reStructuredText:

  \{\{\{
  #!rst
  
  Examples:
  
      * Tickets: :trac:`#1` or :trac:`ticket:1`
      * Ticket comments: :trac:`comment:ticket:1:2`
  \}\}\}
  

• Using raw HTML:

  \{\{\{
  #!html
  
  <div class="test">Test</div>.
  \}\}\}