wiki:SCS_ISSUE_TRACKER_MAINTENANCE_R0
Last modified 16 years ago Last modified on 10/01/08 16:32:54

Error: Macro BackLinksMenu(None) failed
compressed data is corrupt

Analysis

This task includes maintaining the issue tracker.

Overview

  • Maintain the issue tracker regularly;
    • Delete, fix, group, etc - tickets.
    • Make sure tickets are up to date and generally correct.
  • Define and create useful Reports;
  • Review existing tickets.
  • Look for duplicate issues and remove them.
  • Look for unassigned tickets and assign them.
  • Send reminders to owners of tickets without progress (look for comments that contain "estimate" "this will be fixes after" "this can't be fixed" etc.)
  • Notify the team if the count of non-closed tickets is huge (in process of work we should consider what "huge count of tickets" mean.
  • Notify the team for other issues you consider abnormal.

Task requirements

  • Issue Tracker should be well organized.
  • Issue tracker should be up-to-date.
  • Issue tracker should be fully consistent.

Task Result

  • An easily maintainable tracker.

Implementation idea

  • Ticket System Review
    • Priorities should be expanded in the tickets. 'major' is left as default for now.
    • Severities should be defined. Should discuss these with the team.
  • Tickets review and fixing.
    • Unnecessary and not functioning reports removed. New reports added.
    • Should define who the owner of the task would be. Define criteria! Suggestion:
      • The one analyzing it. (possible since proper analysis is the most important part.)
      • The one designing it. (possible since implementation is the task itself done and is dependable on design.)
      • The one implementing it. (possible since implementation is "the task done".)
      • The one reviewing it. (review is also important part to define the owner, since the one reviewing the task is responsible for approval and is hold responsible for the overall process before review IF THE TASK HAS PASSED.)
      • Another proposal: Why not analysis and review be done by one person and he's be the owner. That is one person say what the task is and review whether it is done properly. This may be sensible...
    • Components reviewed.

How to demo

Design

Check the Overview requirements.

  • Review all reports.
  • Review all tickets.
  • Review owners of tasks.
  • Review components.
  • Create Severities.
  • Owner = the one analyzing it, since proper analysis is the most important part.

Implementation

  • Issues are linked with components where possible.
  • The Owner of the ticket will be the one analyzing it, since proper analysis is the most important part.
  • We'll not use Severities.
  • Priorities will be set manually when analyzing the sprint.
  • In SCS_ISSUE_TRACKER_MAINTENANCE_R1 will be nice to implement a better ticket workflow. Following the standard from the wiki task pages, i.e. Analysis, Design, Implementation, Testing, Done phase. In the description of the task ticket can be included the log for the task.

Testing

Log

Error: Macro Include(wiki:SCS_ISSUE_TRACKER_MAINTENANCE_R0_LOG) failed
current transaction is aborted, commands ignored until end of transaction block