Ticket types and severity
Clear definition of the priority that bugs can have:
| Priority | Description |
|---|---|
| Highest | Problem that makes inspectIT as a whole (or very large parts) not useable |
| High | Problem that makes one feature of inspectIT not useable |
| Medium | We do not use this, in order to separate clearer and force us to make the separation |
| Low | Problem that makes part of a feature in certain situations not useable, perhaps workaround is available |
| Lowest | Small problem, whose fix would make things easier |
Clear separation of internal and external tickets
We do a clear separation in the ticket types. We have internal features/improvements and external features/improvements that are usable for the enduser.
| Type | Internal / External | Description | Examples |
|---|---|---|---|
| Bug | External | an error, flaw, failure, or fault in an inspectIT feature that causes it to produce an incorrect or unexpected result, or to behave in unintended ways | |
| Feature | External | New feature or extension of a feature that the end user can see and use | Charting of webbased requests, Download speed in buffer, Structural improvement of the buffer, new communication protocol |
| Epic | External | Signature feature, usually with big efforts. Epics are planned during Release planning | Configuration interface, Business Transactions |
| Internal Feature | Internal | New functionality/technology or improvements that help our process or internal structures, that the end user does not see. Choose Internal Feature over Task if the change needs an integration as tasks are not possible to be integrated. | improvement in ANT build, new version of checkstyle |
| Task | Internal | Internal without code (no merge) | Update Confluence Documentation, Perform performance checks or explorative testing |
| Sub-Task | Internal | Internal without code (no merge) as a subtask of another ticket | |
| Sub-Feature | Internal | Sub Entity that can itself be integrated |
Clear and understandable ticket name for "external" tickets
All external features will have to have a understandable ticket name, that describes the improvement from the view of an enduser. Bugs are also end-user "features" and thus also needs understandable ticket names. Understandable means that a user of inspectIT can understand what this new feature offers
Examples: "Charting of metrics of webbased requests", "Download speed when transfering buffers is shown"
- Describe what the needs-reworks label means
- Describe what the signature label means --> signature feature used in roadmap planning