Ticket Manual

We use the ticket system extensively to define our current and future tasks. Good tickets are easy to follow and will most likely be attended to first. Here are some notes on how to write good tickets.

Short Summary

What fails? What feature do you want to add? What would you like us to do?


  • Creating new Sample, named "#¤%SSS" fails
  • Show file size as a default column
  • Include support for scripting


This field indicates how hard something is to solve. It's often related to the developer accepting the ticket and you should leave it as default(16) if you do not intend to resolve the issue yourself.

1 - Easy

2 - Doable

4 - Difficult

16 - No idea how to solve this

When analyzing severity think about the unknowns in the problem. If you know exactly how to solve the issue the severity is (1). If you have no idea whatsoever on how to solve the issue the severity is (16). Remember that once the issue is investigated further the severity might change.


If you set this to blocker make sure you refer to the blocked ticket[s].


  • core
  • ftpd
  • plugin
  • servlet - graphical issues, exposing features
  • waf - web application framework
  • wiki - documentation and website
Last modified 13 years ago Last modified on Nov 8, 2007, 9:29:55 AM