On 10/03/2012 02:41 PM, Vincent Massol wrote:
Let me rephrase what I said.
Your solution 1 is the best I've seen so far but it won't work unless there's a process associated with it. Who's going
to change the workflow from "new" to "open"? If nobody is in charge it just won't happen and we'll
be in the same situation than we're in now with 10% marked "open" and 90% marked "new"….
IMO when we get an invalid it doesn't stay more than 1 day open. It's closed
very quickly as we monitor issues every day as they come. So I don't really
feel the need to do something else. Of course we might forgot 1 issue in 1000
but that's really not bad :)
Yes, I agree with you. My proposed solutions were better alternatives
than using "Future" to address the issue that "Future" was trying to
address. But IMO the issue is not really important, and it requires
extra work for almost no added benefit.
Thanks
-Vincent
On Oct 3, 2012, at 8:34 PM, Vincent Massol <[email protected]> wrote:
Hi Sergiu,
On Oct 3, 2012, at 6:52 PM, Sergiu Dumitriu <[email protected]> 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
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
