osdir.com


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

Re: JIRA Workflow Proposals


Hey Benedict,
Thank you.

In that case
A D E B C

> On Dec 11, 2018, at 12:37 PM, Benedict Elliott Smith <benedict@xxxxxxxxxx> wrote:
> 
> 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
>> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx