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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
