...
Category | Subcategory | Description |
|---|---|---|
Correctness | Persistent Corruption / Loss | Corruption that persists, and may propagate across the cluster |
| Response Corruption / Loss | Corruption that does not propagate or persist, only results in a client receiving erroneous responses |
| Semantic Failure | The logical behaviour is either not to spec, or the spec is faulty/ambiguous |
| Consistency Failure | Apparently successful action, but with lower consistency than required |
| Test Failure | A test is broken - if this turns out to be a legitimate bug, it should transition to the bug's category once diagnosed |
Availability | Response Crash | An operation does not succeed/respond because of a crash while servicing it, without affecting process stability |
| Process Crash | An isolated exceptional state occurs that brings down the affected node |
| Cluster Crash | A correlated exceptional state occurs across the cluster, bringing down a multiplicity of nodes |
| Unavailable | Apparently unavailable, when should be available |
Degradation | Resource Management | Either a resource leak or overcommit |
| Slow Use Case | A specific use case with suboptimal characteristics that have not yet been accommodated |
| Performance Bug/Regression | Unintended performance behaviour, including e.g. exceptions stalling compactions |
| Other Exception | An exception is being thrown, that is not coinciding with another category of degradation |
Security | Information Leakage |
|
| Privilege Escalation |
|
| Denial of Service |
|
| Remote code execution |
Feature Category
Required. Only provided as an option for the Feature and Improvement issue types.
...
The Reopened state is of dubious value - arguably, it is in any scenario more helpful to file a new ticket, link the two via a relation, and leave a comment on the original for interested parties to migrate to the new discussion. In any case, its use is frowned upon and rare. It will of course remain possible to move a ticket from the 'Resolved' state to e.g. the Open state, but this will not be officially sanctioned except when correcting filing/procedural errors.
New Workflow
| State | Description | Expected Transitions (To) |
|---|---|---|
| Triage | This ticket has been filed, perhaps by a member of the community, but has not been considered by a contributor competent to assess its impact, severity, etc. Before transitioning to Open, the contributor should consider updating the title and summary to best reflect the report in a way the project will understand. | Awaiting Feedback, Open, Resolved |
| Awaiting Feedback | Most beneficial as a cyclical state between Triage and itself, as dialogue takes place to establish any facts needed to understand, categorise and prioritise the report. | Triage, Open, Resolved |
| Open | The ticket is prioritised and well summarised, but work is not yet underway. | In Progress |
| In Progress | The assignee is 'actively' working on this ticket | Patch Available, Open |
| Patch Available | The assignee has a patch that is ready for a reviewer. The assignee should endeavour to solicit from the community a reviewer competent in the subsystem(s) from, if none is already assigned. | Review in Progress |
| Review in Progress | The assigned reviewer is 'actively' reviewing the available patch | Change Requested, Ready to Commit |
| Change Requested | The reviewer has provided feedback for the assignee to consider and incorporate into their patch. Once they are ready to address these points, they should transition the ticket back to 'In Progress' | In Progress |
| Ready to Commit | The reviewer(s) consider this patch to be ready to commit | Resolved |
| Resolved | The ticket has been closed (either successfully or unsuccessfully) |
The column on the right represents the states we will provide buttons for performing a simple transition between. It does not include all acceptable transitions.
...