THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Firstly, we propose the removal of the Wish and Test ticket types.
Issue Type | Reason |
|---|---|
Wish | is a feature/improvement, and can be better communicated via priority/complexity details we will introduce below |
Test | is logically a component, and a non-specific one at that |
Remove Fields
Field | Reason | Migration |
|---|---|---|
Labels | See detailed discussion below | |
Reviewer | Replaced by Reviewers | Populate empty |
Reviewers fields with contents of Reviewer | ||
Environment | Use is very patchy, noisy, and seemingly of little value over a comment if the extra content is useful | Propose new multi-select 'Platform' field with curated option list, in detail below |
Reproduced In | Use is very patchy; seems to offer little practical value above 'Since Version' |
|
Docs Text | Unused |
|
Due Date | Unused |
|
Epic Link | Unused |
|
External Issue ID | Unused |
|
External Issue URL | Unused |
|
Flags | Unused |
|
Sprint | Unused |
|
Time Tracking | Unused |
|
Remove Labels
This field clearly provides some utility today, however this seems almost exclusively to be a hack around the inadequacies
of our current JIRA data model. It is a poor tool for this job, and extremely noisy - there are ~500 labels, of which 300
are used exactly once and only ~100 are used > 5 times. Many of these labels are duplicates of each other, with different
punctuation, spelling or verbiage.
...
Presently, Priority encodes some ill-defined combination of the first three of these independent properties, making it
hard to draw strong conclusions about any of them. We propose introducing two new fields, and clarifying the Priority
terminology to only suggest urgency, as well as reducing the number of priorities, since we don't effectively use them.
Priority
New Priority | Logically Replaces | Migrate From | Details |
|---|---|---|---|
Wish | Wish Issue Type | Wish Issue Type |
|
Low | Low-Minor | Low-Minor |
|
Normal | Minor-Major | Major | It wasn't clear what Minor or Major meant, but priority is a relative concept - a 'normal' is our logical baseline, and the default for a new issue |
High | Rest of Major |
| For tickets that community members plan to prioritise over other outstanding work, but has no immediate urgency |
Urgent | Critical-Blocker | Critical-Blocker | There's limited logical distinction between Critical and Blocker; it seems to make more sense to have a single 'do ASAP' tag |
Complexity
This field will be required, discussed further in the Workflow section below.
Complexity | Description | Initial Value |
|---|---|---|
Low Hanging Fruit | Trivial, No Dependencies, Localised, Accessible to New Contributors | Old Priority = Trivial or label=lhf |
Normal | Unremarkable; default |
|
Challenging | Localised, but requiring sophisticated analysis to understand |
|
Byzantine | Affecting many components, requiring sophisticated analysis to understand |
|
Impossible | Suspect this is not even possible (may be paired with Wish) |
|
Severity
This field will be required, discussed further in the Workflow section below. It will be available only for the Bug issue type.
Severity | Old Priorities | Description |
|---|---|---|
Low | Trivial-Low | Limited usability or low visibility impact with no impact on correctness; no urgency to resolve |
Normal | Minor-Major |
This issue is either unremarkable or extraordinarily rare | ||
Critical | Critical-Urgent | This bug may have significant impact on correctness, availability, stability or some other critical production behaviour |
Discovered By
This field will be required for the Bug issue type. It will be used for analysis of our efforts to establish project quality.
...
Required. Only provided as an option for the Bug issue type. Uses a Cascading Select List.
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 this category when it is 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 | An 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 |
|
Category
Required. Only provided as an option for the Feature and Improvement issue types.
Category | Description |
|---|---|
Performance | |
Change Semantics | Introduce new, or clarify/modify existing database semantic behaviours |
Improve Operability | Reduce the burden of operating a cluster (i.e. handle uncommon states better, with less operator involvement) |
Quality Assurance | Work to improve the guarantees we can make about the stability and correctness of Cassandra |
Component
Presently, the meaning of each component is unclear, even to long-serving project members. As such, it is very inconsistently
used and probably of limited value for analysis. We propose a more granular definition of components that more closely
matches the every day project vernacular.
...
Cascading Select List Variant
Category | Subcategory |
|---|---|
Consistency | Coordination |
| Hints |
| Repair |
| Streaming |
| Bootstrap and Decommission |
| Batch Log |
Cluster Metadata | Ring Membership |
| Gossip |
| Schema |
Local Read/Write | Commit Log |
| Memtable |
| SSTable |
| Caching |
Compaction | General |
| DTCS |
| TWCS |
| LCS |
| STCS |
Config, Startup and Shutdown | Config |
| Startup |
| Shutdown |
| Launch Scripts |
Messaging | Internode |
| native v4 |
| native v5 |
| Thrift |
CQL | Syntax |
| Interpreter |
| UDF |
| UDA |
| UDT |
Observability | JMX |
| Metrics |
| Tracing |
| Logging |
Tools | fql |
| cqlsh |
| nodetool |
| sstable tools (upgrade, verify, etc) |
| bulk load |
| stress |
Testing | dtest |
| unit test |
| fuzz test |
| benchmark |
Documentation | Javadoc |
| Website |
| Blog Post |
Dependencies, Packaging and Build | Dependencies |
| Packaging |
| Build |
Multi-select List Variant
...