On 10 Jun 2014, at 17:03, Xavier Coulon wrote:
Rob,
Sorry, I missed the fact that you were talking about issues you were
looking for help with.
I agree with you that setting a fix version to 4.2.x then later to
4.3.x because 4.2.0 was released is not an ideal solution. I'm not
sure if this would make more sense to keep the fixVersion and assignee
unset until someone really decides to work on it, and automatically
add a 'triage_required' label when the reporter creates the issue, and
then let the component leader remove that label to indicate that the
issue was triaged ? Does it make more sense and less paperwork ?That's
just an idea.
The problem we have is that issues that sits around with fix version =
empty or .x or LATER just gets forgotten.
I don't know of a better way than *Actually* do the triaging of the
issues to move the issues forward to get them triaged and then either
planned (specific version/.x), dropped (closed) or postponed (.x/LATER)
Adding a label i'm not sure will help much - the issues are still not
actually looked at and moved forward (or closed)
/max
Best regards,
/Xavier
On 10 Jun 2014, at 16:19, Rob Stryker <rstryker(a)redhat.com> wrote:
> I'm mostly talking about issues I am basically looking for help with.
> Issues I have no schedule for and don't want to keep pushing off
> every release. Sure, I can put 4.2.x, and then later move to 4.3.0,
> and then later move to 4.3.x, but that seems like a lot of messy
> paperwork and clogs everyone's mailboxes and doesn't clearly mark the
> issue as help wanted.
>
> If I put a fix version on it, it implies it is in my plan. Some of
> these issues are not in my plan, or I have exhausted all attempts to
> discover the causes. It seems very wrong for me to keep pushing them
> off.... but I can't leave them without a fix version or I get a yelly
> email from jiralint ;)
>
> On 06/10/2014 10:16 PM, Xavier Coulon wrote:
>> Hello Rob,
>>
>> As far as I'm concerned, I set the fixVersion to 4.2.x if I know I
>> won't work on the issue before the next code freeze (currently
>> 4.2.0.Beta3), so at least it means that I noticed it but decided not
>> to work on it yet. I set a fix version on all the issues I plan to
>> work on to the next version we'll release, and sometimes I even set
>> the status to "coding in progress", so I can use JIRA filters to
>> find the issues even faster.
>>
>> Feel free to correct me if my method is wrong ;-)
>>
>> Best regards,
>> /Xavier
>>
>>
>>
>> On 09 Jun 2014, at 10:11, Rob Stryker <rstryker(a)redhat.com> wrote:
>>
>>> Hi All:
>>>
>>> Do we have a document available with the proper way to triage
>>> issues? I
>>> seriously have no idea anymore, and every time I try to change an
>>> old
>>> issue, I end up getting an email telling me that it's not triaged
>>> now.
>>>
>>> I used to assign myself, even if I didn't intend to work on it, to
>>> indicate that it "was read". I was told this was incorrect, and
>>> that
>>> there should be no assignee if nobody is actively working on it.
>>>
>>> I also used to mark it as targeted to later, but I was told this
>>> was
>>> vague and should not be used as a dumping ground for all issues
>>> that
>>> aren't on the plan.
>>>
>>> But if I leave the fix version blank (to indicate it is not on my
>>> plan),
>>> I get an email telling me the issue is untriaged.
>>>
>>> I also tried commenting on issues, to indicate that I've seen them,
>>> but
>>> didn't change the fix version or assignee since I did not have a
>>> firm
>>> target for it.... but this gets the same emails.
>>>
>>> Should I go in right now and bulk-change all my unassigned
>>> untargeted
>>> issues to myself with a fix version, even if I have no idea if that
>>> fix
>>> version is accurate? Or should I mark all I don't have a firm
>>> target for
>>> to "Later" ?
>>>
>>> What's the process here?
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
/max
http://about.me/maxandersen