1: A
2: +1
3: +1
4: +1
5: +1
6: +1
> On Dec 4, 2018, at 11:19 AM, Benedict Elliott Smith <bened...@apache.org>
> wrote:
>
> Sorry, 4. Is inconsistent. First instance should be.
>
>> - 4. Priorities: Keep ‘High' priority
>
>
>> On 4 Dec 2018, at 19:12, Benedict Elliott Smith <bened...@apache.org
>> <mailto:bened...@apache.org>> wrote:
>>
>> Ok, so after an initial flurry everyone has lost interest :)
>>
>> I think we should take a quick poll (not a vote), on people’s positions on
>> the questions raised so far. If people could try to take the time to stake
>> a +1/-1, or A/B, for each item, that would be really great. This poll will
>> not be the end of discussions, but will (hopefully) at least draw a line
>> under the current open questions.
>>
>> I will start with some verbiage, then summarise with options for everyone to
>> respond to. You can scroll to the summary immediately if you like.
>>
>> - 1. Component: Multi-select or Cascading-select (i.e. only one component
>> possible per ticket, but neater UX)
>> - 2. Labels: rather than litigate people’s positions, I propose we do the
>> least controversial thing, which is to simply leave labels intact, and only
>> supplement them with the new schema information. We can later revisit if we
>> decide it’s getting messy.
>> - 3. "First review completed; second review ongoing": I don’t think we need
>> to complicate the process; if there are two reviews in flight, the first
>> reviewer can simply comment that they are done when ready, and the second
>> reviewer can move the status once they are done. If the first reviewer
>> wants substantive changes, they can move the status to "Change Request”
>> before the other reviewer completes, if they like. Everyone involved can
>> probably negotiate this fairly well, but we can introduce some specific
>> guidance on how to conduct yourself here in a follow-up.
>> - 4. Priorities: Keep ‘High' priority
>> - 5. Mandatory Platform and Feature. Make mandatory by introducing new “All”
>> and “None” (respectively) options, so always possible to select an option.
>> - 6. Environment field: Remove?
>>
>> I think this captures everything that has been brought up so far, except for
>> the suggestion to make "Since Version” a “Version” - but that needs more
>> discussion, as I don’t think there’s a clear alternative proposal yet.
>>
>> Summary:
>>
>> 1: Component. (A) Multi-select; (B) Cascading-select
>> 2: Labels: leave alone +1/-1
>> 3: No workflow changes for first/second review: +1/-1
>> 4: Priorities: Including High +1/-1
>> 5: Mandatory Platform and Feature: +1/-1
>> 6: Remove Environment field: +1/-1
>>
>> I will begin.
>>
>> 1: A
>> 2: +1
>> 3: +1
>> 4: +1
>> 5: Don’t mind
>> 6: +1
>>
>>
>>
>>
>>> On 29 Nov 2018, at 22:04, Scott Andreas <sc...@paradoxica.net
>>> <mailto:sc...@paradoxica.net> <mailto:sc...@paradoxica.net
>>> <mailto:sc...@paradoxica.net>>> wrote:
>>>
>>> If I read Josh’s reply right, I think the suggestion is to periodically
>>> review active labels and promote those that are demonstrably useful to
>>> components (cf. folksonomy ->
>>> taxonomy<https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy
>>> <https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>
>>> <https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy
>>> <https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>>>). I
>>> hadn’t read the reply as indicating that labels should be zero’d out
>>> periodically. In any case, I agree that reviewing active labels and
>>> re-evaluating our taxonomy from time to time sounds great; I don’t think
>>> I’d zero them, though.
>>>
>>> Responding to a few comments:
>>>
>>> –––
>>>
>>> – To Joey’s question about issues languishing in Triage: I like the idea of
>>> an SLO for the “triage” state. I am happy to commit time and resources to
>>> triaging newly-reported issues, and to JIRA pruning/gardening in general. I
>>> spent part of the weekend before last adding components to a few hundred
>>> open issues and preparing the Confluence reports mentioned in the other
>>> thread. It was calming. We can also figure out how to rotate / share this
>>> responsibility.
>>>
>>> – Labels discussion: If we adopt a more structured component hierarchy to
>>> treat as our primary method of organization, keep labels around for people
>>> to use as they’d like (e.g., for custom JQL queries useful to their
>>> workflows), and periodically promote those that are widely useful, I think
>>> that sounds like a fine outcome.
>>>
>>> – On Sankalp’s question of issue reporter / new contributor burden: I
>>> actually think the pruning of fields on the “new issue form” makes
>>> reporting issues easier and ensures that information we need is captured.
>>> Having the triage step will also provide a nice task queue for screening
>>> bugs, and ensures a contributor’s taken a look + screened appropriately
>>> (rather than support requests immediately being marked “Critical/Blocker”
>>> and assigned a fix version by the reporter).
>>>
>>> – On Sankalp’s question of the non-committer’s workflow during first pass
>>> of review, I think that’s covered here:
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
>>>
>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow>
>>>
>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
>>>
>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow>>
>>>
>>> –––
>>>
>>> I also want to step back and thank Benedict and Kurt for all of their
>>> analysis and information architecture work behind this proposal. "Workflow
>>> and bug tracker hygiene” can be a thankless endeavor; I want to make sure
>>> this one’s not. Thank you both!
>>>
>>> If we’re nearing consensus on “keeping labels, and considering them for
>>> promotion to components periodically,” are there other items we need to
>>> resolve before we generally feel good about the changes?
>>>
>>> – Scott
>>>
>>>
>>> On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith
>>> (bened...@apache.org <mailto:bened...@apache.org>
>>> <mailto:bened...@apache.org
>>> <mailto:bened...@apache.org>><mailto:bened...@apache.org
>>> <mailto:bened...@apache.org> <mailto:bened...@apache.org
>>> <mailto:bened...@apache.org>>>) wrote:
>>>
>>> Hmm. On re-reading your earlier email, I realise I may have anyway gotten
>>> confused about your suggestion.
>>>
>>> Are you suggesting we periodically clear any new labels, once we have
>>> replacements, and only leave the old ones that exist today and haven’t been
>>> categorised?
>>>
>>>
>>>> On 26 Nov 2018, at 23:02, Benedict Elliott Smith <bened...@apache.org
>>>> <mailto:bened...@apache.org>> wrote:
>>>>
>>>> Do we maintain a list of prior rejects? Revisit any that have increased in
>>>> usage since last?
>>>>
>>>> Probably we’re bike shedding this one thing too closely. I would be happy
>>>> with removing it, periodically cleaning it, or leaving it intact. Mining
>>>> it for schema changes, or telling people to ask.
>>>>
>>>> But I fear it will all begin to go to pot again after this effort wanes,
>>>> and my life has only one JIRA cleanup effort to call upon.
>>>>
>>>>
>>>>> On 26 Nov 2018, at 18:24, Joshua McKenzie <jmcken...@apache.org
>>>>> <mailto:jmcken...@apache.org>> wrote:
>>>>>
>>>>> I'm thinking something like "Every 6 months, we query on labels with count
>>>>>> = 4 and consider promoting those. Anything < that only shows if people
>>>>>> are
>>>>> specifically looking for it."
>>>>>
>>>>> Taking count of occurrence of a label as a proxy for the potential value
>>>>> in
>>>>> promoting it to something hardened isn't without flaws, but it's also not
>>>>> awful IMO.
>>>>>
>>>>>
>>>>> On Mon, Nov 26, 2018 at 12:37 PM Benedict Elliott Smith
>>>>> <bened...@apache.org <mailto:bened...@apache.org>>
>>>>> wrote:
>>>>>
>>>>>>> Is there harm in leaving them in, aside from psychologically to all of
>>>>>>> us
>>>>>>> knowing they're there? =/
>>>>>>
>>>>>> It would at least make it easier to triage the ‘new' ones and promote
>>>>>> them. The pain of actually categorising the labels was high, and doing
>>>>>> that every time would mean it never happens (though maybe there are ways
>>>>>> to
>>>>>> work around this). I also think there’s value in shedding noisy data, in
>>>>>> an active process to promote good hygiene.
>>>>>>
>>>>>> But who said our state of mind isn’t also important :)
>>>>>>
>>>>>> This isn’t something I’ll fight hard for, though, I can see it’s at least
>>>>>> partially a preference for cleanliness. Interested to see what others
>>>>>> think.
>>>>>>
>>>>>>> On 26 Nov 2018, at 17:28, Joshua McKenzie <jmcken...@apache.org
>>>>>>> <mailto:jmcken...@apache.org>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> An alternative route might be to support labels, and (e.g.) bi-annually
>>>>>>>> promote any useful ones to the schema, and clear the rest?
>>>>>>>
>>>>>>> +1 to promoting, probably should case-by-case the clearing (but mostly
>>>>>> just
>>>>>>> clear)
>>>>>>>
>>>>>>> The present labels are much too painful to clean up. I categorised the
>>>>>> top
>>>>>>>> 100 or so, and will migrate them (there’s a CSV embedded in the
>>>>>>>> proposal
>>>>>>>> you can look at). The rest have < 5 occurrences, so I cannot see what
>>>>>>>> value they really provide us.
>>>>>>>
>>>>>>> Is there harm in leaving them in, aside from psychologically to all of
>>>>>>> us
>>>>>>> knowing they're there? =/
>>>>>>>
>>>>>>> I _think_ several of your concerns are addressed by the new Triage
>>>>>>> state.
>>>>>>>> The idea is for users to create a ticket without any field
>>>>>>>> requirements.
>>>>>>>> Contributors should liaise with the user to understand the problem, and
>>>>>>>> transition it to Open.
>>>>>>>
>>>>>>> Shit, my bad, totally missed / didn't grok that. That makes a lot more
>>>>>>> sense.
>>>>>>>
>>>>>>> On Mon, Nov 26, 2018 at 11:58 AM Benedict Elliott Smith <
>>>>>> bened...@apache.org <mailto:bened...@apache.org>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Sorry, I failed to respond to point (2) in the aggregate email.
>>>>>>>>
>>>>>>>> I’m not sure it’s worth complicating the flow for this scenario, as the
>>>>>>>> ticket can simply return to ‘Patch Available’. But, I’m really unsure
>>>>>> of
>>>>>>>> the best option here. Does anyone else have any strong opinions /
>>>>>> thoughts?
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 26 Nov 2018, at 14:33, Sankalp Kohli <kohlisank...@gmail.com
>>>>>>>>> <mailto: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
>>>>>>>>>> <mailto: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 <mailto: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>
>>>>>>>>>>> <
>>>>>>>>>>>
>>>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>> <mailto:dev-unsubscr...@cassandra.apache.org>
>> <mailto:dev-unsubscr...@cassandra.apache.org
>> <mailto:dev-unsubscr...@cassandra.apache.org>>
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> <mailto:dev-h...@cassandra.apache.org> <mailto:dev-h...@cassandra.apache.org
>> <mailto:dev-h...@cassandra.apache.org>>
