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 sounds like you may have meant to indicate -1, but not sure. > On 11 Dec 2018, at 20:12, Sylvain Lebresne <lebre...@gmail.com> wrote: > > 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 > <alek...@apple.com.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 <bened...@apache.org> >> 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 <bened...@apache.org> >> 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.jo...@yahoo.com.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.moha...@gmail.com> wrote: >>>>>> >>>>>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith >>>>>> <bened...@apache.org> 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 >>> >>>>>>> >>>>>> >>>>>> 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-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
