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
