On 2018/11/26 13:39:50, Benedict Elliott Smith 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/d
end 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 componen
Sounds great Benedict, its a start for me as again I look forward to
communicating with everyone and helping out, I know I will learn a little
something just from seeing work flow and studying up on what ever task is
presented in front of me.
> On Dec 12, 2018, at 10:14 AM, Benedict Elliott Smi
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#JI
-1
> > >>>> 4: Priorities: Including High +1/-1
> > >>>> 5: Mandatory Platform and Feature: +1/-1
> > >>>> 6: Remove Environment field: +1/-1
> > >>>>
> > >>>> I will begin.
> > >>>>
1. D C B A E
2. B C A
3. A
4. -0.5, leaning towards remove but don't really care
On Tue, Dec 11, 2018 at 06:42:09PM +, Aleksey Yeshchenko wrote:
> 1. C, D, A, B, E
> 2. B, C, A
> 3. A
> 4. Meh
>
> > On 11 Dec 2018, at 16:28, Benedict Elliott Smith
> > wrote:
> >
> > Just to re-summarise th
1: D C B A E
2: B C A
3: A
4: -1 (get rid of Wish entirely)
Thanks,
Sam
> On 11 Dec 2018, at 22:01, Joseph Lynch wrote:
>
> Just my 2c
>
> 1. D C B E A
> 2. B, C, A
> 3. A
> 4. +0.5
>
> -Joey
>
> On Tue, Dec 11, 2018 at 8:28 AM Benedict Elliott Smith
> wrote:
>
>> Just to re-summarise th
Just my 2c
1. D C B E A
2. B, C, A
3. A
4. +0.5
-Joey
On Tue, Dec 11, 2018 at 8:28 AM Benedict Elliott Smith
wrote:
> Just to re-summarise the questions for people:
>
> 1. (A) Only contributors may edit or transition issues; (B) Only
> contributors may transition issues; (C) Only Jira-users ma
Hey Benedict,
Thank you.
In that case
A D E B C
> On Dec 11, 2018, at 12:37 PM, Benedict Elliott Smith
> wrote:
>
> Hi Andre,
>
> It’s ranked vote, i.e. for each question, what is your preference order for
> the outcome?
>
> So, for question 1, the possible outcomes are:
>
> (A) Only contr
Hi Andre,
It’s ranked vote, i.e. for each question, what is your preference order for the
outcome?
So, for question 1, the possible outcomes are:
(A) Only contributors may edit or transition issues;
(B) Only contributors may transition issues;
(C) Only Jira-users may transition issues;
(D) (
Hey everyone,
Im just trying to keep up but I don’t think everyone needs permissions just
contributors im trying to understand the letter voting system so I could better
be of service to the community. Sorry if I sound naive.
> On Dec 11, 2018, at 12:12 PM, Sylvain Lebresne wrote:
>
> 1: D C
Thanks. To clarify, a negative result for Q4 had intended to be interpreted as
the elimination of ‘Wish’ entirely; nobody has indicated any love for the Wish
issue type as yet, so not replacing it would mean it disappears. That is,
unless there are several strong sentiments otherwise.
It soun
1: D C E B A (with a particularly strong feeling against A)
2: A B C
3: A (but don't mind much overall)
4: Don't mind (I neither particularly like 'wish' as a priority or issue
type really)
--
Sylvain
On Tue, Dec 11, 2018 at 7:42 PM Aleksey Yeshchenko
wrote:
> 1. C, D, A, B, E
> 2. B, C, A
> 3.
1. C, D, A, B, E
2. B, C, A
3. A
4. Meh
> On 11 Dec 2018, at 16:28, Benedict Elliott Smith wrote:
>
> Just to re-summarise the questions for people:
>
> 1. (A) Only contributors may edit or transition issues; (B) Only contributors
> may transition issues; (C) Only Jira-users may transition iss
Just to re-summarise the questions for people:
1. (A) Only contributors may edit or transition issues; (B) Only contributors
may transition issues; (C) Only Jira-users may transition issues*; (D)
(C)+Remove contributor role entirely; (E) Leave permission as they are today
2. Priority on Bug issu
It looks like we have a multiplicity of views on permissions, so perhaps we
should complicate this particular vote with all of the possible options that
have been raised so far (including one off-list). Sorry everyone for the
confusion.
(A) Only contributors may edit or transition issues; (B)
>>>>> 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. I
I agree with this. I generally am on the side of freedom and responsibility.
Limiting edits to certain fields turns people off. Something I want to very
much avoid if we can.
Dinesh
> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan
> wrote:
>
> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott S
On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
wrote:
>
> On 10 Dec 2018, at 16:21, Ariel Weisberg 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
> > atta
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
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.
> >>>
>
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:
The “Impact” field idea sounds like a good potential follow-up discussion. I’d
prefer not to complicate this process when we’re seemingly nearing consensus,
particularly as I’m not personally sure what form such a field would take. But
it would be a relatively small modification, if you want t
> Of course, if we remove Priority from the Bug type, I agree with others
> that the top level priority ceases to mean anything, and there probably
> shouldn’t be one.
Benedict, another idea, and this might be for down the road, is to have
"Severity" or bug types and "Impact" on non-bug typ
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
>>>>> t
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
> >>
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
den: 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
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
ead 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
>
>> 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
>>
>
> 1:
> 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
>
1: A
2: +1
3:
t; – 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 th
e (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
>>> actual
> – 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
> 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
>
1: A
2: +1
3: +1
4: +1
; 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
> >> 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 issue
re
>> 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
>>
gt;> 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
>>
;>>>>>> developer working on it, I think that makes sense.
> >>>>>>>>
> >>>>>>>> 3) Priority Changes: to be blunt, this looks like shuffling
> chairs on
> >>>>>> the
> >>>>>>>> dec
s 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 burd
ide 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
nsures 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’
n
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
elf
>>>>> 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:
>>>>&
ore 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 i
es 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
;> 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
>>>>
r 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?
> >>
> >>
roblems 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&#
ertain 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
losophically, 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 im
ng 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*,
>
s / 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
ms 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 i
ict Elliott Smith
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/JI
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 w
58 matches
Mail list logo
