osdir.com

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

Re: JIRA Workflow Proposals


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
<aleksey@xxxxxxxxx.invalid> 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 <benedict@xxxxxxxxxx>
> 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
> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
> they are today
> > 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
> >
> > With my answers (again, sorry):
> >
> > 1: A B C D E
> > 2: B C A
> > 3: A
> > 4: +0.5
> >
> >> On 11 Dec 2018, at 16:25, Benedict Elliott Smith <benedict@xxxxxxxxxx>
> wrote:
> >>
> >> 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) 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
> >>
> >> * Today apparently ‘Anyone’ can perform this operation
> >>
> >> A ranked vote, please.  This makes my votes:
> >>
> >> 1: A B C D E
> >> 2: B C A
> >> 3: A
> >> 4: +0.5
> >>
> >>
> >>> On 11 Dec 2018, at 05:51, Dinesh Joshi <dinesh.joshi@xxxxxxxxx.INVALID>
> wrote:
> >>>
> >>> 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 <
> murukesh.mohanan@xxxxxxxxx> wrote:
> >>>>
> >>>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
> >>>> <benedict@xxxxxxxxxx> wrote:
> >>>>>
> >>>>>> On 10 Dec 2018, at 16:21, Ariel Weisberg <ariel@xxxxxxxxxxx> 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
> >
> >>>>>
> >>>>
> >>>> That would be disappointing. Descriptions with broken or no formatting
> >>>> aren't rare (say, command output without code formatting). And every
> >>>> now and then the description might need to be updated. For example, in
> >>>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to
> the
> >>>> paper had rotted, but I managed to find a new one, so I could edit it
> >>>> in. If such a change had to be posted as a comment, it might easily
> >>>> get lost in some of the more active issues.
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> 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
>
>