Ticket_procedure

A formal procedure for the life of a bug ticket is as follows:

• Reporting phase
  1. A concerned person ("reporter") discovers a bug.
  2. Reporter attempts to reproduce the bug. In the case of Errors,
     if it doesn't reproduce, continue anyways.
  3. Reporter files a ticket with as much information as possible. An
     outline of reporting tickets is documented at Bug
     reporting.
• Tech phase
  1. A tech lead receives the ticket.
  2. Tech lead attempts to reproduce the bug and fills out the ticket
     with any additional information and tags as appropriate. Note
     that at this point, there may be insufficient information, at
     which point the tech lead will attempt to collect more
     information from the reporter. Tickets like this should to be
     tagged as "Needs Information" or "Needs Feedback". If the tech
     lead is familiar with the problem/solution, he may give a rough
     outline of what work needs done.
  3. Generally the tech lead should also include a test case for QA.
     Usually this is just the steps to reproduce.
  4. Ticket is assigned a priority, which may fast-track it into
     development or may put it into the backlog, at which point it
     can be pulled into development whenever a new dev phase starts
     (in Agile, this is at the beginning of a "sprint", which is
     usually 2 weeks).
• Sprint phase
  1. Team lead reviews the ticket with the devs, gives an estimate,
     assigns the ticket, and effectively pulls it into the sprint
     (meaning it will be worked on this sprint).
  2. At this time, the ticket may be cleaned up a little to more
     accurately reflect the issue.
  3. Developer documents work and issues until the problem is fixed.
  4. Developer refactors code so that it's clean and in line with the
     philosophy of the product.
  5. Developer attempts to confirm that the issue is fixed. Updates
     the test case as necessary (including any exclusions for things
     that QA should not fail the ticket for - usually due to it being
     addressed in a separate ticket). Pushes code into review (this
     effectively closes the ticket as In Review and pushes the code
     into a team repository).
• QA phase
  1. Team lead and/or tech lead reviews the fix. Pushes the code into
     the global repository. Pushes it into QA (this effectively
     re-opens the ticket as Begin QA).
  2. QA tests the parts of the product relating to the ticket on
     their own, clean environment. This is outlined in the test case.
     Ultimately, the test case needs to pass for the ticket to pass.
     If the test case fails, the fix fails. If the test case passes,
     QA should also do a basic regression test, or a more thorough
     regression test for fixes that affect many aspects of the
     product - for fixes that it is unclear what they affect, it
     would generally warrant a Full regression test. If anything
     seems wonky, especially if any of the steps leading up to the
     test case cannot be followed, QA will fail the ticket. Failed
     tickets go back to dev (who may decide to exclude the reason of
     failure and/or clarify the test case, and push it back into QA.
     Alternatively, they may fix the regression and push it back into
     review).
  3. QA phase 2 repeats the QA process in a production environment.
     This step may be skipped if a "production environment" is the
     same as a development environment.
  4. QA passes the fix, formally closes the ticket as resolved.

Note that, as a small team, we do not have the resources to follow this
formal procedure. We do not have nearly enough people to fill all the
roles, and even if we did, the people we have are all volunteers,
meaning they are under no obligation to fulfill their role, let alone to
fulfill it in a reasonable time frame. Because of this, much of this
process is expidited as much as possible, compressing several steps, and
creating informal processes for these. Whatever the case, this formal
procedure forms a guideline in what the procedure for a ticket
*should* be, so that our informal processes may reflect this as best
is possible with the resources we have.

Do realize that tickets and bugs do still fall through the cracks. To
best expedite a ticket, we ask that reporters stick around and check up
on the ticket throughout the life of the ticket, helping in whatever way
they can. The reporter is also capable of closing their own tickets,
should they feel they are invalid or resolved before the usual ticket
process completes - that's perfectly fine. However, you are not required
to close your tickets - they will follow their usual lifecycle and get
closed off eventually anyways (hopefully by QA).