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
luence 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 pe
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 fo
t; 5: Mandatory Platform and Feature: +1/-1
> > >>>> 6: Remove Environment field: +1/-1
> > >>>>
> > >>>> I will begin.
> > >>>>
> > >>>> 1: A
> > >>>> 2: +1
> > >>>&g
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
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
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
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
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
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
>
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
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
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)
lt;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-ev
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
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
> >
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” st
>>> 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 st
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 prun
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
> 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
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/garden
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,
se 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 an
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
&
;>>>> 4: Priorities: Including High +1/-1
>>>>> 5: Mandatory Platform and Feature: +1/-1
>>>>> 6: Remove Environment field: +1/-1
>>>>>
>>>>> I will begin.
>>>>>
>>>>> 1
t; 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
>
>> 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
> 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 thre
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 issue
t;> 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 + screen
> 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
t;
> > >> 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
> > >> r
sues, 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 rotat
>> 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.
>>
es: 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 t
ike (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
>
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-c
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’
x 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
;>>> 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
>>>
gt;> 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.
>>>>>>
>>>>>> Th
ics, 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 t
>>>> 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
ing 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
t; 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 start
X 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
gt; 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 JI
>> 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 /
t; 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 start
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 a
uce 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 c
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>
56 matches
Mail list logo
