Guidelines for Creating a New Ticket

When Should I Create a New Ticket?

If you have a feature request that you or have found a bug, you should be creating a new ticket.

Support and installation questions should be asked on the mailing list or IRC channel, not filed as tickets. Be sure to review the mailing list archives first, as a lot of common installation and usage issues are already covered there.

Is There a Similar Ticket Already in Existance?

Please check whether your feature request/bug has been reported already. If it has, please comment on that ticket rather than create a new one.

When you have an error message, it's a good idea to copy/paste it in the search box, enclosed in quotes (for an exact match).

If not, pick a few keywords and do a search on them. If you have a more precise knowledge about the issue, you can try a custom query, where you can easily filter tickets based on various criteria.

If you still aren't sure…

Go ahead and create the new ticket anyway, we won't get upset at you ;)

What Now?

So the issue you want to report has not been addressed before, and you're confident it's about time to create a new ticket for it.

Please follow those guidelines:

  • Provide a concise and precise Summary. As when you write an e-mail, the ticket's summary is the first thing people will see about this ticket, in the timeline, reports and other places in in the hub, so it's quite important to get it right.
  • What's the appropriate Ticket Type? Is this a Defect report or an Enhancement request? A defect is an existing feature not working as described, adding a missing feature is an enhancement request, however important that feature is to you (you can use the severity field for ranking that).
  • The Description is the place where you give all the details about the issue. Good descriptions for a problem report are the ones that make it easy for the developer to understand and/or reproduce the problem. To that end, it's usually necessary to give the following information:
    • How To Reproduce: describe what you were doing when the problem happened. Someone following those instructions should be able to reproduce the problem.
    • System Information: list the software components involved with their version
      • the Operating System and version
      • the database version
  • The following ticket fields should be correctly set:
    • The Version of the phpTimeClock software you were using. This can usually be seen in the bottom right of the phpTimeClock window
    • The Component specifies the subsystem of phpTimeClock in which the error happened or where the enhancement should be made
    • The Severity is a rough estimation of the impact of the problem or the importance of the enhancement
    • The Keywords can contain a few important words about the issue
  • The following ticket fields can be left as they are:
    • The Assign to person will be deduced from the choice of the component
    • The Priority will be arbitrarily set by a Trac developer ;)
    • The Milestone will be set after the ticket triage. An empty milestone means the ticket has not yet been triaged.

Please take all these guidelines with a grain of salt, those are not strict rules, only hints for improving the ongoing development process of phpTimeClock.