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 +0000, 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 <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
