On 09/01/2013, at 12:48 PM, Szczepan Faber wrote: > In jira, we used to have a 'component' field (or something like that), > to group issues into things like 'eclipse', 'tooling-api', etc. It was > useful at times, at least for me (though I admit not every issue had > it declared).
How did you use it? > Just to make sure: at the moment, we don't want any > field for this kind of information? > > Cheers! > > On Fri, Jan 4, 2013 at 9:00 PM, Adam Murdoch > <[email protected]> wrote: >> >> On 04/01/2013, at 8:01 PM, Szczepan Faber wrote: >> >> I'm wondering about a custom field with the 'pain level'. Sometimes >> users (and us) give feedback on how painful the problem is and it >> might be useful to filter/sort by this. In a some minimal way the >> 'priority' field played this role in past (for example, myself and >> some other users used 'low' priority for issues that are just minor >> inconveniences). >> >> >> I wouldn't bother adding such field. I never use the priority field when >> scheduling which issues to fix. Generally, I think it's pretty low quality >> data. Instead, I think votes are a better way to measure pain. People also >> tend to mention their pain level in their comments. >> >> >> Not pushing for this - just raising a thought for future consideration. >> >> Cheers! >> >> On Fri, Jan 4, 2013 at 1:44 AM, Adam Murdoch >> <[email protected]> wrote: >> >> >> On 03/01/2013, at 11:11 PM, Luke Daley wrote: >> >> >> I have made some changes to JIRA. >> >> >> 1. There is no longer a “Resolved” status, only “Closed” >> >> >> >> Is there any chance we can keep 'resolved' instead of 'closed', or tweak the >> >> workflow so that we can change issues after they are closed? It's a pain >> >> having to reopen an issue so that I can put the 'fix version' in that we've >> >> forgotten to add, or where we've put the wrong version in. >> >> >> >> -- >> >> Adam Murdoch >> >> Gradle Co-founder >> >> http://www.gradle.org >> >> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting >> >> http://www.gradleware.com >> >> >> >> >> >> -- >> Szczepan Faber >> Principal engineer@gradleware >> Lead@mockito >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >> >> -- >> Adam Murdoch >> Gradle Co-founder >> http://www.gradle.org >> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting >> http://www.gradleware.com >> > > > > -- > Szczepan Faber > Principal engineer@gradleware > Lead@mockito > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
