Thanks Jo for the feedback too!
I’ll keep my responses brief as there are already a lot of discussions in
flight.
> On 26 Nov 2018, at 16:24, Joseph Lynch <joe.e.ly...@gmail.com> wrote:
>
> Benedict,
>
> Thank you for putting this document together, I think something like this
> will really improve the quality and usefulness of the Jira tickets!
>
> A few pieces of overall feedback on the proposal:
> * I agree with Jeremy and Joshua on keeping labels. Labels are the only way
> that contributors without access to the Jira project configuration can use
> to try to group related tickets together and while I agree stronger and
> well curated components are valuable, labels are a valuable supplement (and
> they natively work with search so you can link to a group of tickets really
> easily)
Let’s engage on this further in the other discussion to avoid fragmentation.
> * Throughout the text there are various elements only available for bugs or
> features or both (e.g. Bug Category vs Feature Category), which I find hard
> to keep track of in the body of the text. Maybe we can separate the
> document into "Bug Fields" and "Feature Fields" ("Improvement Fields"?)?
Most fields affect everything, but the only new fields that are bug-specific
are actually adjacent right now: Severity, Bug Category and Discovered By. I
will try to make this clearer. The only feature-specific field is its bug
counterpart (i.e. Feature Category, or Change Category).
> * I think it's pretty odd that only "jira contributors" can assign tickets
> (even to themselves), and this proposal seems to make that go further in
> that contributors are the only ones who can move tickets out of triage into
> the open state. I'm somewhat concerned that tickets will just languish in
> triage state and unassigned because the person who cut the issue can't move
> it to open and can't assign themselves to fix it... If we had an SLO on
> triage like "an expert in the tagged category will triage new tickets
> within three days" I'd feel different but I'm not sure how/if we can offer
> that. To be clear I like the Triage/Awaiting Feedback state to indicate
> that we need more details from the reporter, but I think if a ticket stays
> in Triage for more than some amount of time it should be because a
> contributor has triaged it and has asked for more information and not
> because nobody is looking (maybe we should even auto-close triage state
> tickets after some period of inactivity).
Yes, one absolute goal of Triage is that we use it to ensure tickets are
promptly answered (triaged) by a contributor knowledgeable in the area. These
are all great suggestions, and I have my own ideas here, but this is probably
out of scope. This change hopefully provides a foundation, and we can follow
up with a separate discussion on how to best utilise it?
> * Can we clarify how users can receive emails on Jiras awaiting triage
> (perhaps a mailing list they can join that gets emails when Jiras are
> cut). I know this would really help me with knowing that new Jiras have
> been cut and I can help triage them or something and afaik it isn't
> currently possible/documented.
Right now the commits@ mailing list sends out all JIRA changes, and it would be
easy to filter to new creations. You can also have JIRA email you the tickets
that answer a query (e.g. those in the Triage state).
> I'm still reading through the entire document, but so far I have the
> following specific feedback:
> * Instead of "Since Version" I'd recommend just having "Versions" for all
> issues since bugs can apply in earlier version but not later ones. "Fix
> Versions" then refers to the versions that have any fix or commit related
> to that bug/feature.
My only concern here is that there is no way to create a range. This would be
optimal, but ‘Version(s)’ implies listing all affected versions, which would be
impossible! And 3.0.x is not practical, since it could affect only versions
3.0.3 - 3.0.11, say. I’m open to JIRA-compatible suggestions here?
> * For "Platform" should we include an "Other" field that allows users to
> provide additional free-form context? I know that having a free form text
> has helped me provide additional context like "NVMe SSDs" so that reviewers
> don't start with "have you checked your drives are not slow". Worst case
> this can be included in the description but personally I like separation of
> environment description from bug/improvement description.
If we maintain the ‘Environment’ field as proposed in the other thread we can
capture this there, but I would prefer we try to capture this in the Platform
options as quickly as possible. A quick message to #cassandra-dev on IRC, or
an email to dev@ should let somebody quickly add this option, and I will add it
to the list now - which is definitely not complete as yet.
> * Huge +1 to the "Review in Progress" vs "Change Requested", that will
> really help new contributors know when they need to make changes.
> * For the workflow how can we provide some guidance for contributors to get
> high level feedback before they get to the "Patch Available", maybe we
> explicitly indicate that before transitioning to "In Progress" the reviewer
> should be found on IRC or the mailing list and they should have signed off
> on the high level idea/issue? Maybe this should be part of the new "Triage"
> step? I feel one of the more frustrating issues for new contributors is to
> do the work and then get the "well what if you did it a completely
> different way" feedback.
These sound like great ideas. Once we agree the schema, I hope we can use the
wiki as a starting point for how-to guide, and this should definitely be
incorporated.
I don’t think incorporating it into Triage is ideal, though - we don’t want to
create too high a barrier to moving things to Open IMO.
This is genuinely a difficult issue, though, as people are busy so don’t get
involved until they see problems materialise. Newer contributors soliciting
early feedback in the design before (or during) ‘In Progress’ is going to help,
but unfortunately getting negative feedback after implementation and before
commit is an inherent risk in the community. We all experience it, no matter
how long we’ve been on the project.
>
> I'll try to finish internalizing the rest of the document later today and
> provide more specific feedback. Thanks again for starting this discussion
> and I look forward to the resulting updates!
>
> -Joey
>
> On Mon, Nov 26, 2018 at 7:06 AM Jeremy Hanna <jeremy.hanna1...@gmail.com>
> wrote:
>
>> Regarding labels, I am personally a fan of both - the mapping of commonly
>> used labels to things like components, features, tools, etc. as well as
>> keeping labels for newer and more arbitrary groupings. I’ve tried to
>> maintain certain labels like virtual-tables, lcs, lwt, fqltool, etc because
>> there are new things (e.g. fqltool and virtual tables) that we don’t
>> immediately make into components and it's really nice to group them to see
>> where there might be stability or feature specific (thinking virtual
>> tables) items. I agree that arbitrary and misspelled labels make things a
>> bit noisy but as long as we strive to use the components/features and do
>> some periodic upkeep of labels. By periodic upkeep I mean, converting new
>> labels into components or what have you. Beyond new features or arbitrary
>> groupings, it might have been nice to have had ngcc labeled tickets to see
>> how that’s contributed to the project over time or some other similar event.
>>
>> In summary, I really like the mapping but I also really like the way that
>> labels can still be of value. Also, if we strive to keep the components
>> field up to date, there’s really no harm in having the labels.
>>
>> </2cents>
>>
>> Jeremy
>>
>>> On Nov 26, 2018, at 8:33 AM, Sankalp Kohli <kohlisank...@gmail.com>
>> wrote:
>>>
>>> I have following initial comments on the proposal.
>>> 1. Creating a JIRA should have few fields mandatory like platform,
>> version, etc. We want to put less burden on someone creating a ticket but I
>> feel these are required for opening bugs.
>>>
>>> 2. What is the flow when a non committer does the first pass of review?
>>>
>>>
>>>
>>>> On Nov 26, 2018, at 7:46 PM, Joshua McKenzie <jmcken...@apache.org>
>> wrote:
>>>>
>>>> 1) Removal of labels: one of the strengths of the current model is
>>>> flexibility for groupings of concepts to arise from a user-perspective
>>>> (lhf, etc). Calcifying the label concepts into components, categories,
>> etc.
>>>> is a strict loss of functionality for users to express and categorize
>> their
>>>> concerns with the project. This feels like an over-correction to our
>>>> current lack of discipline cleaning up one-off labels. Counter-proposal:
>>>>
>>>> 1. We beef up the categories and components as proposed and migrate
>>>> labels to those
>>>> 2. We remove the one-off labels that aren't adding value, considering
>>>> aggregating similar labels
>>>> 3. We leave the "labels" field intact, perhaps with a bit of guidance
>> on
>>>> how to effectively use it
>>>>
>>>> 2) Required fields on transition: assuming these are required upon
>> *issue
>>>> creation*, that's placing a significant burden on a user that's seen
>>>> something and wants to open a ticket about it, but isn't sure if it's a
>>>> "Semantic Failure" or a "Consistency Failure", for instance. If this is,
>>>> instead, a field required for transition to other ticket states by the
>>>> developer working on it, I think that makes sense.
>>>>
>>>> 3) Priority Changes: to be blunt, this looks like shuffling chairs on
>> the
>>>> deck of the titanic on this one - in my experience, most users aren't
>> going
>>>> to set the priority on tickets when they open them (hence default ==
>> major
>>>> and most tickets are opened as major), so this is something that will be
>>>> either a) left alone so as not to offend those for whom the priority is
>>>> *actually* major or consistent with the default, or b) changed by the
>> dev
>>>> anyway and the added signal from a new "High vs. Urgent" distinction and
>>>> communication of developer intent to engage with a ticket is something
>>>> that'll be lost on most users that are just reporting something. I don't
>>>> have a meaningful counter-proposal at this point as the current problem
>> is
>>>> more about UX on this field than the signal / noise on the field itself
>> IMO.
>>>>
>>>> A meta question about the "What and Why" of what we're trying to
>> accomplish
>>>> here: it sounds like what you're looking at is:
>>>>
>>>> 1. to capture more information
>>>> 2. simplify the data entry
>>>> 3. nudge people towards more complete and accurate data entry
>>>> 4. our ability as a project to measure release quality over time and
>>>> identify when Cassandra is ready for (or due a) release.
>>>>
>>>> The proposal in its current form makes certain strong inroads in all of
>>>> those 4 metrics, but I think the major thing missing is the UX of what
>>>> we're thinking about changing:
>>>>
>>>> 1. Making it easy for / reduce friction for users to report bugs and
>>>> requests into the project JIRA (easy to do things right, hard to do
>> things
>>>> wrong) (current proposal is a +1 on "do things right", though I'd argue
>>>> against it being *easy*)
>>>> 2. Asking from the users what they can provide about their experience
>>>> and issues and no more
>>>>
>>>> Philosophically, are we trying to make it easier for people that are
>> paid
>>>> FT to work on C*, are we trying to make things easier for *users* of C*,
>>>> both, neither? Who are we targeting here w/these project changes and
>> what
>>>> of their issues / problems are we trying to improve?
>>>>
>>>> And lastly: the TLC and management of the JIRA aspects of this project
>> have
>>>> *definitely* languished (not pointing any fingers here, I'm *at least*
>> as
>>>> guilty as anyone on this :) ) - so a big thanks to you and whomever
>> you've
>>>> collaborate with in getting this conversation started!
>>>>
>>>> On Mon, Nov 26, 2018 at 8:39 AM Benedict Elliott Smith <
>> bened...@apache.org>
>>>> wrote:
>>>>
>>>>> We’ve concluded our efforts to produce a proposal for changes to the
>> JIRA
>>>>> workflow, and they can be found here:
>>>>>
>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>>>>> <
>>>>>
>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>>>>>>
>>>>>
>>>>> I hope there will be broad consensus, but I’m sure it won’t be plain
>>>>> sailing. It would be great to get a discussion going around the
>> proposal,
>>>>> so please take some time to read and respond if you think you’ll have a
>>>>> strong opinion on this topic.
>>>>>
>>>>> There remains an undecided question in our initial proposal, that is
>>>>> highlighted in the wiki. Specifically, there was no seemingly
>> objective
>>>>> winner for the suggested changes to Component (though I have a
>> preference,
>>>>> that I will express in the ensuing discussion).
>>>>>
>>>>> Other contentious issues may be:
>>>>> - The removal of ‘labels’ - which is very noisy, the vast majority of
>>>>> which provide no value, and we expect can be superseded by other
>> suggestions
>>>>> - The introduction of required fields for certain transitions, some of
>>>>> which are new (complexity, severity, bug/feature category)
>>>>> - The introduction of some new transitions (Triage, Review in Progress,
>>>>> Change Requested)
>>>>>
>>>>> Look forward to hearing your thoughts!
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
