osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JIRA Workflow Proposals


1: A
2: +1
3: +1
4: +1
5: Meh. +0
6: +1

On Wed, Dec 5, 2018 at 2:57 PM Jonathan Haddad <jon@xxxxxxxxxxxxx> wrote:

> My personal preference is to remove labels, but I don't see it as a huge
> issue if they stay.
>
> 1. A
> 2. prefer to remove (I suppose I'm a -.1?)
> 3. +1
> 4. +1
> 5. No preference
> 6. +1
>
>
>
> On Wed, Dec 5, 2018 at 11:43 AM jay.zhuang@xxxxxxxxx.INVALID
> <jay.zhuang@xxxxxxxxx.invalid> wrote:
>
> >  1: Component. (A) Multi-select
> > 2: Labels: leave alone +1
> > 3: No workflow changes for first/second review: +1
> > 4: Priorities Including High: -1
> > 5: Mandatory Platform and Feature: +1
> > 6: Remove Environment field: +1
> >
> >     On Wednesday, December 5, 2018, 2:58:21 AM PST, Benedict Elliott
> Smith
> > <benedict@xxxxxxxxxx> wrote:
> >
> >  Thanks for the feedback and further questions.  I’m sure there will be
> > more, particularly around permissions and roles, so it’s good to get some
> > of these other discussions moving.
> >
> > No doubt we’ll do a second poll once the first one concludes.  Please,
> > everyone, keep your first poll answers coming!
> >
> > > On 5 Dec 2018, at 09:50, Sylvain Lebresne <lebresne@xxxxxxxxx> wrote:
> > >
> > > Thanks for all those that contributed to the proposal, and specifically
> > to
> > > Benedict for leading the discussion.
> > >
> > > On the general proposal, I suspect there is a few details we may have
> to
> > > tweak going forward, but hard to be sure before trying and as I do
> think
> > > it's progress, I'm personally happy to move forward with this. But for
> > the
> > > sake of discussions, a minor remarks that I don't think have been
> > mentioned
> > > above:
> > > - at least the platform and feature fields will be moving targets (the
> > > features hopefully more so than the platform, but new java version gets
> > > release regularly for instance). Do we know technically if we can get
> > those
> > > easily updated without requiring an infra JIRA ticket?
> >
> > This is actually a really good question.  I had assumed this would be
> > treated much like Component, Version, etc
> >
> > However, I was wrong:
> >
> >
> https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311
> > <
> >
> https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311
> > >
> >
> > There are some possible workarounds, but none of them seem great.
> There’s
> > a plugin, but not sure if Infra would be OK with this:
> >
> https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server&tab=overview
> > <
> >
> https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server&tab=overview
> > >
> >
> > This is potentially a real blocker for these two fields.
> >
> > So, for feature an alternative is to merge Feature/[Feature] into
> > Component.  This would implicitly make it non-mandatory, however.  This
> > could potentially be fixed with a custom field validator, but this might
> > need a plugin.
> >
> > For Platform, I don’t have a good alternative idea right now.  This is
> > something that is best curated, but definitely needs to be easily
> updated.
> >
> >
> > > - I'd personally probably remove the condition of being "jira
> > contributor"
> > > to move tickets out of triage. Being a "jira contributor" is a pretty
> > > arbitrary in practice. Anyone that ever asked has been added, no
> question
> > > asked, but it can actually be annoying to get added if no-one that
> knows
> > > how to do it is around. So if, as I assume, the goal is to ensure that
> > > fields are properly fielded, I don't think it will help much, and so I
> > > suspect it would just be an annoyance to new, not-yet-"jira
> contributor"
> > > users that are willing to fill all the required fields seriously (but
> > will
> > > see their ticket stuck in triage until they either get added, or some
> > other
> > > random user flip the switch). And why assume people will mis-field
> > stuffs?
> > > So I'd vote for just letting anyone transition out of triage as long as
> > all
> > > required field are there. Side-note: fwiw, I'd very much be in favor of
> > > removing the "jira contributor" concept for the reasons exposed above:
> I
> > > never felt it was anything else than an hindrance.
> >
> > I realise we have no real barrier to becoming a contributor, and that
> many
> > of these permissions are going to have limited impact.  But I think a
> > really easy to jump gate can still be helpful, and I don’t recall
> > contributors overstepping their role.  But this isn’t a critical point,
> and
> > it would be great to hear other’s opinions.
> >
> > > - Once we have 'complexity' and 'severity', I'm not entirely sure what
> > > 'priority' really means in a voluntary-based project? Is it the
> > gut-feeling
> > > for how useful the ticket is of whomever triage the ticket? If that,
> > > outside of not being convinced of the value, I'd argue that 1) it
> doesn't
> > > make sense for bugs and 2) it's sufficiently imprecise that it's imo
> > worth
> > > keeping it simple, something like low/normal/high ought to be enough.
> If
> > > it's not that, then what is it, cause it's genuinely not immediately
> > > obvious to me?
> >
> > Well, if nothing else Priority is the thing I sort my outstanding work
> by,
> > and for this reason I have a preference for it being present for all
> ticket
> > types.  But I do see your point.
> >
> > In particular, Urgent probably is something we’re only likely to use for
> > critical bugs.  It’s possible we could even automatically populate this
> for
> > a Bug type, and potentially not show this option for non-bugs.  But I
> > suspect we would need something like the ScriptRunner plugin for this.
> >
> > In my view Priority is essentially Low or Normal (or Urgent if critical
> > bug) on initial filing.  But a High priority can be set by a contributor
> > who particularly values the ticket, for their own work prioritisation.
> > Wish is a priority to make room for the Wish ticket type we are removing,
> > and for those occasional requests that come in that have no realistic
> > timeline for being addressed.
> >
> >
> > >
> > > And with that, my poll results:
> > > 1:A
> > > 2:+1
> > > 3:+1
> > > 4:Don't mind
> > > 5:Don't mind
> > > --
> > > Sylvain
> > >
> > >
> > > On Tue, Dec 4, 2018 at 8:12 PM Benedict Elliott Smith <
> > benedict@xxxxxxxxxx>
> > > 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: Option A: Wish, Low, Normal, High, Urgent; Option B:
> > >> Wish, Low, Normal, Urgent
> > >> - 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 <scott@xxxxxxxxxxxxxx>
> 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>). 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
> > >>>
> > >>> –––
> > >>>
> > >>> 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 (
> > >> benedict@xxxxxxxxxx<mailto:benedict@xxxxxxxxxx>) 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 <
> benedict@xxxxxxxxxx
> > >
> > >> 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 <jmckenzie@xxxxxxxxxx>
> > >> 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 <
> > >> benedict@xxxxxxxxxx>
> > >>>>> 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 <jmckenzie@xxxxxxxxxx>
> > >> 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 <
> > >>>>>> benedict@xxxxxxxxxx>
> > >>>>>>> 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 <
> kohlisankalp@xxxxxxxxx>
> > >>>>>> 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 <
> > >> jmckenzie@xxxxxxxxxx>
> > >>>>>>>> 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 <
> > >>>>>>>> benedict@xxxxxxxxxx>
> > >>>>>>>>>> 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-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > >>>>>>>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >> ---------------------------------------------------------------------
> > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > >>>>>>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > ---------------------------------------------------------------------
> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > >>>>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> > >>>>>>
> > >>>>>>
> > >>>>
> > >>>>
> > >>>>
> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > >>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> > >>>>
> > >>>
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > >>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> > >>>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > >> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> > >>
> > >>
> >
>
>
>
> --
> Jon Haddad
> http://www.rustyrazorblade.com
> twitter: rustyrazorblade
>