3 Oct
2012
3 Oct
'12
8:34 p.m.
Hi Sergiu,
On Oct 3, 2012, at 6:52 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 10/03/2012 11:44 AM, Vincent Massol wrote:
Hi devs,
It seems we've never really used the "future' version in jira. I'd like
like to propose to remove it.
The idea was that issues that had been reviewed and marked for later were supposed to use
"future" but in practice we are not doing it.
WDYT?
The goal is to see which issues have been triaged, so that: - issues don't go unnoticed
- users know that we've acknowledged their report
This is 1) not needed and 2) means nothing. It's not because you've put
"future" on some issue that it gives any real information to the user. It's
better to tell them that anytime they enter an issue it won't be forgotten which is
the current situation (even if it may take long to tackle).
Differentiating between issues that we're OK to
address and those that we don't agree with should be done by closing issues as
wontfix.
Yep so no need for future for that.
Marking issues for which there is some progress should
be done by marking them as inprogress.
Yep
I agree that using the fix for field isn't
semantically correct, so +1 for removing it. But we still need to track triaged issues.
1. How about adding a new value to the issue state? "New" means a new issue
that hasn't been reviewed, "Open" means that it's an issue that has been
reviewed and considered valid. This is similar to what others are doing, especially with
Bugzilla.
2. How about adding a new field that better tracks progress, like what we recently
introduced for tracking pull request status. The possible states could be:
- new, waiting for review
- waiting for user feedback
- accepted
- work started
- stalled
- done
Personally I prefer 1, since 2 is getting too bureaucratic for my taste.
My point was about being realistic. I don't agree with either 1 or 2 because it'll
never work.
3 points:
* We don't need to track triaged issues. Why would we need to do that? All we need is
close issues that we don't want to fix or that are dups or cannot reproduce.
* If one day we consider an issue as "good to fix in the future" then it
doesn't mean it's going to be true 1 month later because we may have implemented a
feature that replaces it and makes it useless or less interesting.
* It's just too much work. Look at the current state and tell me if it represents the
reality…
IMO what we just need to do is have regular "JIRA cleanup day" (which can be
combined with Bug Fixing Day since this is what I personally do when there's a BFD and
I find it a good time) and review issues during that day to perform some cleanup. By
cleanup I mean:
* Find duplicates
* Won't fix/cannot reproduce
For me doing anything more is not only a waste of time but not going to work.
I'm against any solution that 1) doesn't represent the reality (ie isn't
always up to date) or 2) doesn't bring enough added value for the associated work.
Thanks
-Vincent