My two cents:
1. C, D, E, B, A2. A, B, C3. A4. -1
On Wednesday, December 12, 2018, 10:14:25 AM PST, Benedict Elliott Smith
<bened...@apache.org> wrote:
Ok, so feel free to keep your votes coming, but we have a pretty clear
majority for everything except Wish - which presently stands at -1 (maybe -2 if
Sylvain updates his vote).
Thanks everyone who has voted on either poll!
Results so far:2. [B C A] x6 [A B C] x13. A x74. +1 -2
For 1, we have:D C B A ED C B A ED C B E AD C E B AA D E B CA B C D EE D C B AC
D A B E
Which currently leads to eliminating B, C and E first choice votes, leading to
a strong win for option D.
I’ll leave it a few days to see if anymore votes roll in, but I don’t
anticipate a major shift in opinion. I will update the proposal with the
outcome, and call a formal vote on the final proposal in a few days.
Thanks again everyone for participating in what I realise was not the most
exciting discussion. I’m glad everyone got a chance to air their opinions, and
that we managed to come to a decision that I hope we can all endorse.
On 12 Dec 2018, at 16:00, Ariel Weisberg <ar...@weisberg.ws> wrote:
Hi,
Updating to reflect the new options for 1. 2, 3, and 4 remain unchanged.
1. E, D, C, B, A
2. B, C, A
3. A
4. -.5
Ariel
On Tue, Dec 11, 2018, at 10:55 AM, Ariel Weisberg wrote:
Hi,
Sorry I was just slow on the uptake as to what auto-populate meant RE #2.
1. -1, while restricting editing on certain fields or issues that people
did not submit themselves is OK I don't think it's reasonable to block
edits to subject, or description on issues a user has submitted.
Do we actually have a problem that needs solving with restricting edits?
I feel like we aren't being harmed right now by the current power people
are wielding?
2. B, C, A
3. A
4. -.5, I really don't see Wish as something other then a synonym for
low priority. Only -.5 because I don't think it's that harmful either.
Ariel
On Mon, Dec 10, 2018, at 8:51 PM, Benedict Elliott Smith wrote:
On 10 Dec 2018, at 16:21, Ariel Weisberg <ar...@weisberg.ws> wrote:
Hi,
RE #1, does this mean if you submit a ticket and you are not a contributor you
can't modify any of the fields including description or adding/removing
attachments?
Attachment operations have their own permissions, like comments.
Description would be prohibited though. I don’t see this as a major
problem, really; it is generally much more useful to add comments. If
we particularly want to make a subset of fields editable there is a
workaround, though I’m not sure anybody would have the patience to
implement it:
https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
<https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html>
RE #2, while bugs don't necessarily have a priority it's helpful to have it
sort logically with other issue types on that field. Seems like ideally what we
want to preserve is a useful sort order without having to populate the field
manually.
Do you have a suggestion that achieves this besides auto-populating (if
that’s even possible)? More than happy to add suggestions to the list.
RE #4, Do we need to keep wish at all?
I’m unclear on what you’re asking? I included exactly this question,
directly in response to your opinion that it should not be kept. If you
have more to add to your earlier view, please feel free to share it.
Not voting yet just because I'm not sure on some.
Ariel
On Mon, Dec 10, 2018, at 7:43 AM, Benedict Elliott Smith wrote:
New questions. This is the last round, before I call a proper vote on
the modified proposal (so we can take a mandate to Infra to modify our
JIRA workflows).
Thanks again to everyone following and contributing to this discussion.
I’m not sure any of these remaining questions are critical, but for the
best democratic outcome it’s probably worth running them through the
same process. I also forgot to include (1) on the prior vote.
1. Limit edits to JIRA ‘contributor’ role: +1/-1
2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C)
leave it. Please rank.
3. Top priority: (A) Urgent; (B) Blocker. See here for my explanation
of why I chose Urgent
<https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
<https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E>>.
4. Priority keep ‘Wish’ (to replace issue type): +1/-1
For 2, if we cannot remove it, we can make it non-editable and default
to Normal; for auto-populate I propose using Severity (Low->Low, Normal-
Normal, Critical->Urgent). No guarantees entirely on what we can
achieve, so a ranked choice would be ideal.
I have avoided splitting out another vote on the Platform field, since
everyone was largely meh on the question of mandatoriness; it won by
only a slim margin, because everyone was +/- 0, and nobody responded to
back Ariel’s dissenting view.
My votes are:
1: +1
2: B,C,A
3: A
4: +0.5
For tracking, the new consensus from the prior vote is:
1: A (+10)
2: +9 -0.1
3: +10
4: +6 -2 (=+4)
5: +2; a lot of meh.
6: +9
On 7 Dec 2018, at 17:52, Ariel Weisberg <ar...@weisberg.ws> wrote:
Hi,
Late but.
1. A
2. +1
3. +1
4. -1
5. -0
6. +1
RE 4, I think blocker is an important priority. High and urgent mean the same
thing to me. Wish is fine, but that is too similar to low if you ask me. My
ideal would be low, medium, high, blocker. Medium feels weird, but it's a real
thing, it's not high priority and we really want it done, but it's not low
enough that we might skip it/not get to it anytime soon.
RE 5. I don't think I have ever used the environment field or used the contents
populated in it. Doesn't mean someone else hasn't, but in terms of making the
easy things easy it seems like making it required isn't so high value? I don't
populate it myself usually I put it in the description or the subject without
thinking.
It seems like the purpose of a field is to make it indexable and possibly
structured. How often do we search or require structure on this field?
Ariel
On Tue, Dec 4, 2018, at 2:12 PM, Benedict Elliott Smith 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 <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>). 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
(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> 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> 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>
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> 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>
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>
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
---------------------------------------------------------------------
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>
For additional commands, e-mail: dev-h...@cassandra.apache.org
<mailto: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
