Re: JIRA Workflow Proposals

2018-12-12 Thread Sylvain Lebresne 
On Wed, Dec 12, 2018 at 7:14 PM Benedict Elliott Smith 
wrote:

> Ok, so feel free to keep your votes coming, but we have a pretty clear
> majority for everything except Wish - which presently stands at -1 (maybe
> -2 if Sylvain updates his vote).
>

Yes, I did meant -1 on the wish issue if that can help.


>
> Thanks everyone who has voted on either poll!
>
>
> Results so far:
> 2. [B C A] x6 [A B C] x1
> 3. A x7
> 4. +1 -2
>
> For 1, we have:
> D C B A E
> D C B A E
> D C B E A
> D C E B A
> A D E B C
> A B C D E
> E D C B A
> C D A B E
>
> Which currently leads to eliminating B, C and E first choice votes,
> leading to a strong win for option D.
>
> I’ll leave it a few days to see if anymore votes roll in, but I don’t
> anticipate a major shift in opinion.  I will update the proposal with the
> outcome, and call a formal vote on the final proposal in a few days.
>
> Thanks again everyone for participating in what I realise was not the most
> exciting discussion.  I’m glad everyone got a chance to air their opinions,
> and that we managed to come to a decision that I hope we can all endorse.
>
>
> On 12 Dec 2018, at 16:00, Ariel Weisberg  wrote:
>
> Hi,
>
> Updating to reflect the new options for 1. 2, 3, and 4 remain unchanged.
>
> 1. E, D, C,  B, A
>
> 2. B, C, A
>
> 3. A
>
> 4. -.5
>
> Ariel
> On Tue, Dec 11, 2018, at 10:55 AM, Ariel Weisberg wrote:
>
> Hi,
>
> Sorry I was just slow on the uptake as to what auto-populate meant RE #2.
>
> 1. -1, while restricting editing on certain fields or issues that people
> did not submit themselves is OK I don't think  it's reasonable to block
> edits to subject, or description on issues a user has submitted.
>
> Do we actually have a problem that needs solving with restricting edits?
> I feel like we aren't being harmed right now by the current power people
> are wielding?
>
> 2. B, C, A
>
> 3. A
>
> 4. -.5, I really don't see Wish as something other then a synonym for
> low priority. Only -.5 because I don't think it's that harmful either.
>
> Ariel
>
> On Mon, Dec 10, 2018, at 8:51 PM, Benedict Elliott Smith wrote:
>
> On 10 Dec 2018, at 16:21, Ariel Weisberg  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
> >
>
> RE #2, while bugs don't necessarily have a priority it's helpful to have
> it sort logically with other issue types on that field. Seems like ideally
> what we want to preserve is a useful sort order without having to populate
> the field manually.
>
>
> Do you have a suggestion that achieves this besides auto-populating (if
> that’s even possible)?  More than happy to add suggestions to the list.
>
> RE #4, Do we need to keep wish at all?
>
>
> I’m unclear on what you’re asking?  I included exactly this question,
> directly in response to your opinion that it should not be kept.  If you
> have more to add to your earlier view, please feel free to share it.
>
> Not voting yet just because I'm not sure on some.
>
> Ariel
>
> On Mon, Dec 10, 2018, at 7:43 AM, Benedict Elliott Smith wrote:
>
> New questions.  This is the last round, before I call a proper vote on
> the modified proposal (so we can take a mandate to Infra to modify our
> JIRA workflows).
>
> Thanks again to everyone following and contributing to this discussion.
> I’m not sure any of these remaining questions are critical, but for the
> best democratic outcome it’s probably worth running them through the
> same process.  I also forgot to include (1) on the prior vote.
>
> 1. Limit edits to JIRA ‘contributor’ role: +1/-1
> 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
>
> For 2, if we cannot remove it, we can make it non-editable and default
> to Normal; for auto-populate I propose using Severity (Low->Low, Normal-
>
> Normal, Critical->Urgent).  No guarantees entirely on what we can
>
> achieve, s

Re: Revisit the proposal to use github PR

2018-12-12 Thread dinesh.jo...@yahoo.com.INVALID 
I've been already using github PRs for some time now. Once you specify the 
ticket number, the comments and discussion are persisted in Apache Jira as work 
log so it can be audited if desired. However, committers usually squash and 
commit the changes once the PR is approved. We don't use the merge feature in 
github. I don't believe github we can merge the commit into multiple branches 
through the UI. We would need to merge it into one branch and then manually 
merge that commit into other branches. The big upside of using github PRs is 
that it makes collaborating a lot easier. Downside is that it makes it very 
difficult to follow along the progress in Apache Jira. The messages that github 
posts back include huge diffs and are aweful.
Dinesh 

On Thursday, December 13, 2018, 1:10:12 AM GMT+5:30, Benedict Elliott Smith 
 wrote:  
 
 Perhaps somebody could summarise the tradeoffs?  I’m a little concerned about 
how it would work for our multi-branch workflow.  Would we open multiple PRs?

Could we easily link with external CircleCI?

It occurs to me, in JIRA proposal mode, that an extra required field for a 
permalink to GitHub for the patch would save a lot of time I spend hunting for 
a branch in the comments.




> On 12 Dec 2018, at 19:20, jay.zhu...@yahoo.com.INVALID wrote:
> 
> It was discussed 1 year's ago: 
> https://www.mail-archive.com/dev@cassandra.apache.org/msg11810.html
> As all Apache projects are moving to gitbox: 
> https://reference.apache.org/committer/github, should we revisit that and 
> change our review/commit process to use github PR?A good example is 
> Spark:"Changes to Spark source code are proposed, reviewed and committed via 
> Github pull requests" (https://spark.apache.org/contributing.html).
> /jay


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: cassandra-stress HexStrings generator

2018-12-12 Thread Benedict Elliott Smith 
Yes, I’m pretty sure you understood correctly (I wrote most of this, but it’s 
been a long time so I cannot remember much for certain).  

It should be implemented like the Strings generator.  It looks like both 
HexStrings and HexBytes are incorrect, and have been for a long time.


> On 12 Dec 2018, at 22:27, Saleil Bhat (BLOOMBERG/ 731 LEX) 
>  wrote:
> 
> Hi, 
> 
> I have a question about the behavior of the HexStrings value generator in the 
> cassandra-stress tool, particularly concerning its population/identity 
> distribution.  
> 
> 
> Per the discussion in JIRA item CASSANDRA-6146 concerning the stress YAML 
> profile, the population field in a columnspec “represents the total unique 
> population distribution of that column across rows.”
> 
> 
> I interpreted this to mean that if I specify some distribution 'F' for a 
> column, then the probability of occurrence for each potential value of that 
> column is given by 'F'. 
> 
> So, for example, if I provided the following columnspec for a text column: 
>  name: fake_column 
>   size: fixed(32) 
> population: gaussian(1..100)  
> and then generated a large amount of data according to this specification, 
> I would expect there to be 100 distinct values for ‘fake_column’, and that a 
> histogram of the frequency of occurrence of each value would be roughly 
> bell-shaped. 
> 
> 
> 
> However, the current implementation of the HexStrings generator deviates from 
> this expectation. In the current implementation, each CHARACTER in the string 
> is drawn from F, rather than the string as a whole. Therefore, if you plot 
> the histogram of frequency of occurrence for each character, you get a 
> bell-shaped curve, but the distribution of the occurrences of whole strings 
> (the actual columns) is something else. 
> 
> 
> My question is, is this the desired behavior for string columns? Was my 
> expectation/interpretation incorrect? If so, can anyone give some insight as 
> to why strings are designed to behave this way and what the use case is for 
> this behavior? 
> 
> Thanks, 
> -Saleil 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

cassandra-stress HexStrings generator

2018-12-12 Thread Saleil Bhat (BLOOMBERG/ 731 LEX) 
Hi, 

I have a question about the behavior of the HexStrings value generator in the 
cassandra-stress tool, particularly concerning its population/identity 
distribution.  


Per the discussion in JIRA item CASSANDRA-6146 concerning the stress YAML 
profile, the population field in a columnspec “represents the total unique 
population distribution of that column across rows.”


I interpreted this to mean that if I specify some distribution 'F' for a 
column, then the probability of occurrence for each potential value of that 
column is given by 'F'. 

So, for example, if I provided the following columnspec for a text column: 
  name: fake_column 
   size: fixed(32) 
 population: gaussian(1..100)  
and then generated a large amount of data according to this specification, 
I would expect there to be 100 distinct values for ‘fake_column’, and that a 
histogram of the frequency of occurrence of each value would be roughly 
bell-shaped. 



However, the current implementation of the HexStrings generator deviates from 
this expectation. In the current implementation, each CHARACTER in the string 
is drawn from F, rather than the string as a whole. Therefore, if you plot the 
histogram of frequency of occurrence for each character, you get a bell-shaped 
curve, but the distribution of the occurrences of whole strings (the actual 
columns) is something else. 


My question is, is this the desired behavior for string columns? Was my 
expectation/interpretation incorrect? If so, can anyone give some insight as to 
why strings are designed to behave this way and what the use case is for this 
behavior? 

Thanks, 
-Saleil 


Re: JIRA Workflow Proposals

2018-12-12 Thread andre wilkinson 
Sounds great Benedict, its a start for me as again I look forward to 
communicating with everyone and helping out, I know I will learn a little 
something just from seeing work flow and studying up on what ever task is 
presented in front of me.

> On Dec 12, 2018, at 10:14 AM, Benedict Elliott Smith  
> wrote:
> 
> Which currently leads to eliminating B, C and E first choice votes, leading 
> to a strong win for option D.
> 
> I’ll leave it a few days to see if anymore votes roll in, but I don’t 
> anticipate a major shift in opinion.  I will update the proposal with the 
> outcome, and call a formal vote on the final proposal in a few days.
> 
> Thanks again everyone for participating in what I realise was not the most 
> exciting discussion.  I’m glad everyone got a chance to air their opinions, 
> and that we managed to come to a decision that I hope we can all endorse.

Re: Revisit the proposal to use github PR

2018-12-12 Thread Benedict Elliott Smith 
Perhaps somebody could summarise the tradeoffs?  I’m a little concerned about 
how it would work for our multi-branch workflow.  Would we open multiple PRs?

Could we easily link with external CircleCI?

It occurs to me, in JIRA proposal mode, that an extra required field for a 
permalink to GitHub for the patch would save a lot of time I spend hunting for 
a branch in the comments.




> On 12 Dec 2018, at 19:20, jay.zhu...@yahoo.com.INVALID wrote:
> 
> It was discussed 1 year's ago: 
> https://www.mail-archive.com/dev@cassandra.apache.org/msg11810.html
> As all Apache projects are moving to gitbox: 
> https://reference.apache.org/committer/github, should we revisit that and 
> change our review/commit process to use github PR?A good example is 
> Spark:"Changes to Spark source code are proposed, reviewed and committed via 
> Github pull requests" (https://spark.apache.org/contributing.html).
> /jay


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Revisit the proposal to use github PR

2018-12-12 Thread jay.zhu...@yahoo.com.INVALID 
It was discussed 1 year's ago: 
https://www.mail-archive.com/dev@cassandra.apache.org/msg11810.html
As all Apache projects are moving to gitbox: 
https://reference.apache.org/committer/github, should we revisit that and 
change our review/commit process to use github PR?A good example is 
Spark:"Changes to Spark source code are proposed, reviewed and committed via 
Github pull requests" (https://spark.apache.org/contributing.html).
/jay

Re: JIRA Workflow Proposals

2018-12-12 Thread jay.zhu...@yahoo.com.INVALID 
 My two cents:
1. C, D, E, B, A2. A, B, C3. A4. -1
On Wednesday, December 12, 2018, 10:14:25 AM PST, Benedict Elliott Smith 
 wrote:  
 
 Ok, so feel free to keep your votes coming, but we have a pretty clear 
majority for everything except Wish - which presently stands at -1 (maybe -2 if 
Sylvain updates his vote).
Thanks everyone who has voted on either poll!

Results so far:2. [B C A] x6 [A B C] x13. A x74. +1 -2
For 1, we have:D C B A ED C B A ED C B E AD C E B AA D E B CA B C D EE D C B AC 
D A B E
Which currently leads to eliminating B, C and E first choice votes, leading to 
a strong win for option D.
I’ll leave it a few days to see if anymore votes roll in, but I don’t 
anticipate a major shift in opinion.  I will update the proposal with the 
outcome, and call a formal vote on the final proposal in a few days.
Thanks again everyone for participating in what I realise was not the most 
exciting discussion.  I’m glad everyone got a chance to air their opinions, and 
that we managed to come to a decision that I hope we can all endorse.


On 12 Dec 2018, at 16:00, Ariel Weisberg  wrote:
Hi,

Updating to reflect the new options for 1. 2, 3, and 4 remain unchanged.

1. E, D, C,  B, A

2. B, C, A

3. A

4. -.5

Ariel
On Tue, Dec 11, 2018, at 10:55 AM, Ariel Weisberg wrote:

Hi,

Sorry I was just slow on the uptake as to what auto-populate meant RE #2.

1. -1, while restricting editing on certain fields or issues that people 
did not submit themselves is OK I don't think  it's reasonable to block 
edits to subject, or description on issues a user has submitted. 

Do we actually have a problem that needs solving with restricting edits? 
I feel like we aren't being harmed right now by the current power people 
are wielding?

2. B, C, A

3. A 

4. -.5, I really don't see Wish as something other then a synonym for 
low priority. Only -.5 because I don't think it's that harmful either.

Ariel

On Mon, Dec 10, 2018, at 8:51 PM, Benedict Elliott Smith wrote:

On 10 Dec 2018, at 16:21, Ariel Weisberg  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
 



RE #2, while bugs don't necessarily have a priority it's helpful to have it 
sort logically with other issue types on that field. Seems like ideally what we 
want to preserve is a useful sort order without having to populate the field 
manually.


Do you have a suggestion that achieves this besides auto-populating (if 
that’s even possible)?  More than happy to add suggestions to the list.


RE #4, Do we need to keep wish at all?


I’m unclear on what you’re asking?  I included exactly this question, 
directly in response to your opinion that it should not be kept.  If you 
have more to add to your earlier view, please feel free to share it.


Not voting yet just because I'm not sure on some.

Ariel

On Mon, Dec 10, 2018, at 7:43 AM, Benedict Elliott Smith wrote:

New questions.  This is the last round, before I call a proper vote on 
the modified proposal (so we can take a mandate to Infra to modify our 
JIRA workflows).  

Thanks again to everyone following and contributing to this discussion.  
I’m not sure any of these remaining questions are critical, but for the 
best democratic outcome it’s probably worth running them through the 
same process.  I also forgot to include (1) on the prior vote.

1. Limit edits to JIRA ‘contributor’ role: +1/-1
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 
>.
4. Priority keep ‘Wish’ (to replace issue type): +1/-1

For 2, if we cannot remove it, we can make it non-editable and default 
to Normal; for auto-populate I propose using Severity (Low->Low, Normal-

Normal, Critical->Urgent).  No guarantees entirely on what we can 

achieve, so a ranked choice would be ideal.

I have avoided splitting out another vote on the Platform field, since 
everyone was largely meh on the question of mandatoriness; it won by 
only a slim margin, be

Re: JIRA Workflow Proposals

2018-12-12 Thread Ariel Weisberg 
Hi,

Updating to reflect the new options for 1. 2, 3, and 4 remain unchanged.

1. E, D, C,  B, A

2. B, C, A

3. A

4. -.5

Ariel
On Tue, Dec 11, 2018, at 10:55 AM, Ariel Weisberg wrote:
> Hi,
> 
> Sorry I was just slow on the uptake as to what auto-populate meant RE #2.
> 
> 1. -1, while restricting editing on certain fields or issues that people 
> did not submit themselves is OK I don't think  it's reasonable to block 
> edits to subject, or description on issues a user has submitted. 
> 
> Do we actually have a problem that needs solving with restricting edits? 
> I feel like we aren't being harmed right now by the current power people 
> are wielding?
> 
> 2. B, C, A
> 
> 3. A 
> 
> 4. -.5, I really don't see Wish as something other then a synonym for 
> low priority. Only -.5 because I don't think it's that harmful either.
> 
> Ariel
> 
> On Mon, Dec 10, 2018, at 8:51 PM, Benedict Elliott Smith wrote:
> > On 10 Dec 2018, at 16:21, Ariel Weisberg  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
> >  
> > 
> > 
> > > RE #2, while bugs don't necessarily have a priority it's helpful to have 
> > > it sort logically with other issue types on that field. Seems like 
> > > ideally what we want to preserve is a useful sort order without having to 
> > > populate the field manually.
> > 
> > Do you have a suggestion that achieves this besides auto-populating (if 
> > that’s even possible)?  More than happy to add suggestions to the list.
> > 
> > > RE #4, Do we need to keep wish at all?
> > 
> > I’m unclear on what you’re asking?  I included exactly this question, 
> > directly in response to your opinion that it should not be kept.  If you 
> > have more to add to your earlier view, please feel free to share it.
> > 
> > > Not voting yet just because I'm not sure on some.
> > > 
> > > Ariel
> > > 
> > > On Mon, Dec 10, 2018, at 7:43 AM, Benedict Elliott Smith wrote:
> > >> New questions.  This is the last round, before I call a proper vote on 
> > >> the modified proposal (so we can take a mandate to Infra to modify our 
> > >> JIRA workflows).  
> > >> 
> > >> Thanks again to everyone following and contributing to this discussion.  
> > >> I’m not sure any of these remaining questions are critical, but for the 
> > >> best democratic outcome it’s probably worth running them through the 
> > >> same process.  I also forgot to include (1) on the prior vote.
> > >> 
> > >> 1. Limit edits to JIRA ‘contributor’ role: +1/-1
> > >> 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 
> > >>  > >>  
> > >> >.
> > >> 4. Priority keep ‘Wish’ (to replace issue type): +1/-1
> > >> 
> > >> For 2, if we cannot remove it, we can make it non-editable and default 
> > >> to Normal; for auto-populate I propose using Severity (Low->Low, Normal-
> > >>> Normal, Critical->Urgent).  No guarantees entirely on what we can 
> > >> achieve, so a ranked choice would be ideal.
> > >> 
> > >> I have avoided splitting out another vote on the Platform field, since 
> > >> everyone was largely meh on the question of mandatoriness; it won by 
> > >> only a slim margin, because everyone was +/- 0, and nobody responded to 
> > >> back Ariel’s dissenting view.
> > >> 
> > >> My votes are:
> > >> 1: +1
> > >> 2: B,C,A
> > >> 3: A
> > >> 4: +0.5
> > >> 
> > >> 
> > >> For tracking, the new consensus from the prior vote is:
> > >> 1: A (+10)
> > >> 2: +9 -0.1
> > >> 3: +10
> > >> 4: +6 -2 (=+4)
> > >> 5: +2; a lot of meh.
> > >> 6: +9
> > >> 
> > >> 
> > >> 
> > >>> On 7 Dec 2018, at 17:52, Ariel Weisberg  wrote:
> > >>> 
> > >>> Hi,
> > >>> 
> > >>> Late but.
> > >>> 
> > >>> 1. A
> > >>> 2. +1
> > >>> 3. +1
> > >>> 4. -1
> > >>> 5. -0
> > >>> 6. +1
> > >>> 
> > >>> RE 4, I think blocker is an important priority. High and urgent mean 
> > >>> the same thing to me. Wish is f

Re: JIRA Workflow Proposals

2018-12-12 Thread Marcus Eriksson 
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 +, 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  
> > 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 
> >  >  
> > >.
> > 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  
> >> 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  
> >>> 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 
>   wrote:
>  
>  On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>   wrote:
> > 
> >> On 10 Dec 2018, at 16:21, Ariel Weisberg  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
> >  
> > 
> > 
>  
>  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.

Re: JIRA Workflow Proposals

2018-12-12 Thread Sam Tunnicliffe 
1: D C B A E
2: B C A
3: A 
4: -1 (get rid of Wish entirely)

Thanks,
Sam


> On 11 Dec 2018, at 22:01, Joseph Lynch  wrote:
> 
> Just my 2c
> 
> 1. D C B E A
> 2. B, C, A
> 3. A
> 4. +0.5
> 
> -Joey
> 
> On Tue, Dec 11, 2018 at 8:28 AM Benedict Elliott Smith 
> 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 
>> 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 
>> 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
>  wrote:
>> 
>>> On 10 Dec 2018, at 16:21, Ariel Weisberg  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