This aims to be the central source of information about ''Tickets'' in rasdaman and their management.

= Tickets processing workflow =
Along the lines of the built in [wiki:TracWorkflow trac workflow], with respect to ticket assignments we have in place:
 1. If the ticket '''''owner''''' is not specified at the time of ticket creation, it gets '''''assigned''''' automatically to the component owner;
 2. A ticket can then be '''''assigned''''' further to the person that would be the most appropriate for handling or solving it.
 3. Once a person starts working on a ticket he has to '''''accept''''' the ticket (so we are all aware that it is being worked on actively)
 4. If on an accepted ticket one expects to stop working for long (e.g. more than 2-3 weeks) the ticket should be ''re-assigned'' (eventually to oneself)
  * the ticket should be brought to a "stable" ''progress update'' point with an interim patch (to be confirmed)

From the above we have that:
 * Any ticket that is in '''new''' or '''assigned''' status can be sent to other people or anyone can volunteer to work on it (contacting the current owner for guidance or discussing it on the [MailingLists dev list] is a good option for that);
 * Any ticket that is currently '''accepted''' is expected to be under work and get either ''regular status updates'' or patch submissions towards its resolution. The owner of such a ticket has to be contacted before changes highly relevant to it are made or before reassignment or acceptance by someone else.

Once a ticket is '''resolved''' and the tested patch submitted it can be closed. Whoever wants to test it or see if it has already been integrated into the dev/release lines or packaged for release can check via git log (ticket linking is enforced by naming conventions on patch manager):

{{{
git log | grep 'ticket:NUM' -B4
}}}

As good habit a reference to the related [WikiFormatting#TracLinks changeset] might also be added to the ticket once the patch is applied for cross-reference.

* Every patch referring to a ticket shall (must!) have a reference to it in the title/description for back reference in the form `ticket:<code>`, see our [StandardsAndGuideLines guidelines].

 Ticket pollution problem::
   If the solution of the tickets deserves a ''deeper discussion'' with the mailing lists (or with single devs), it is good to spawn it outside the ticket comments onto e-mail or whatever means, and to provide there only concise and useful conclusions.

= See also =
 * How to file new tickets at [wiki:ReportBug]
 * Overall standards and guidelines for development and process management at [wiki:StandardsAndGuideLines]