THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- Removal of issues types: Wish and Test
- Fields
- Removed: Labels, Reviewer, Environment, Reproduced In, Docs Text, Due Date, Epic Link, External Issue Id, External Issue URL, Flags, Sprint, Time Tracking
- Modified: Priority, Component
- Added: Complexity, Feature, Impacts, Test and Documentation Plan, Platform
- Added (Bug only): Severity, Bug Category, Discovered By
- Added (Improvement and Feature only): Change Category
- Workflow
- New States: Triage, Review in Progress, Change Requested
- Transitions with required fields
- Order of field display changed
- Issue Permissions
- Anybody may file a Triage ticket
- Contributor role will be removed, and in all places replaced with jira-users.
- Only jira-users Only contributors will be permitted to edit transition a ticket , and transition it further in the workflow
- Schema Permissions
- Only committers will be permitted to introduce new options to the schema for the fields: Component, Feature, Platform. Removals can be negotiated with the person who introduced them, or litigated on list.
- All other fields should not have their schema-defined options modified without endorsement from the mailing list.
...
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. We can insert a comment with the environment text for any tickets containing it presently. | ||
Reproduced In | Use is very patchy; seems to offer little practical value above 'Since Version' or a comment. | |||
Docs Text | Unused |
| ||
Due Date | Unused |
| ||
Epic Link | Unused |
| ||
External Issue ID | Unused |
| ||
External Issue URL | Unused |
| ||
Flags | Unused |
| ||
Sprint | Unused |
| ||
Time Tracking | Unused |
|
...
Migrate 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.
We have analysed all labels with >= 5 usages, and made sure they can all be represented in the changes we propose to the
data model.
remap cassandra jira labels.csv
Modifying/Expanding Existing Fields
Priority, Complexity, Severity and Category
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
...
Feature request that has no commitment from anyone to be worked on. Typically reserved for features that
...
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. This should be limited to issues that need to be resolved prior to the next release.
All labels that provide utility to the project and can be represented in the new schema should be migrated to the new schema, but the original labels will be left intact.
remap cassandra jira labels.csv
Modifying/Expanding Existing Fields
Priority, Complexity, Severity and Category
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 |
|---|---|---|---|
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. This should be limited to issues that should both block (until completed) and accelerate (once completed) the next release. |
For the Bug type, this field will be auto-populated (if possible).
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) |
|
Bug Only Fields
Severity
This field will be required, discussed
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)
...
Bug Only Fields
Severity
This field will be required, discussed further in the Workflow section below. It will be available only for the Bug issue type.
...
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.
There are two possible approaches, either using a Cascading Select List or a multi-select list, each with a tradeoff.
The former does not permit multiple selections, but the latter produces a lengthier list - however auto-completion should
make it manageable.
The biggest difficulty here will be migration. It might be that a "Legacy" component is the best option, with the old
scheme replicated exactly. We can then manually migrate tickets as the value presents itself, or organise such a transition.
This question in particular should be put to a discussion on the dev list before being put to a vote.
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
...
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
" component is the best option, with the old schema replicated exactly. We can then manually migrate tickets as the value presents itself, or organise such a transition.
Multi-select ListMulti-select List Variant
Consistency/Coordination
Consistency/Hints
Consistency/Repair
Consistency/Streaming
Consistency/Bootstrap and Decommission
Consistency/Batch Log
Cluster/Membership
Cluster/Gossip
Cluster/Schema
Local/Commit Log
Local/Memtable
Local/SSTable
Local/Caching
Local/Compaction
Local/Compaction/DTCS
Local/Compaction/TWCS
Local/Compaction/LCS
Local/Compaction/STCS
Local/Config
Local/Startup
Local/Shutdown
Local/Scripts
Messaging/Internode
Messaging/Native v4
Messaging/Native v5
Messaging/Thrift
CQL/Syntax
CQL/Interpreter
Observability/JMX
Observability/Metrics
Observability/Tracing
Observability/Logging
Tools/fql
Tools/cqlsh
Tools/nodetool
Tools/sstable
Tools/bulk load
Tools/stress
Tests/dtest
Tests/unit
Tests/fuzz
Tests/benchmark
Docs/Javadoc
Docs/Website
Docs/Blog
Packaging
Dependencies
Build
...
Required fields on transition to 'Open'
- Component
- Feature
- Priority
- Complexity
- Bug/Change Category
- Severity (if bug)
- Discovered By (if bug)
Required fields on transition to 'Patch Available'
- Impacts
- Platform
- Test and Documentation Plan
...