osdir.com


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

Re: JIRA Workflow Proposals


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) (C)+Remove contributor role entirely; 
(E) Leave permission as they are today

Sylvain’s vote was D C E B A, meaning he prefers option D first, option C second, option E third, etc.

There are multiple ranked voting <https://en.wikipedia.org/wiki/Ranked_voting> schemes, but unless anyone objects I will resolve the answers with instant-runoff voting <https://en.wikipedia.org/wiki/Instant-runoff_voting>, which is equivalent to single transferable voting <https://en.wikipedia.org/wiki/Single_transferable_vote> when there is only a single outcome, as there is here.


> On 11 Dec 2018, at 20:25, andre wilkinson <antonio_w3@xxxxxx.INVALID> wrote:
> 
> 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 <lebresne@xxxxxxxxx> 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
>> <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
>>> 
>>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
>