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). 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


Reply via email to