I don`t know, for me it`s good to be able to see which issues are in our "queue", besides the great sea of not yet processed issues :) I agree that we don`t use it much, but I would not go as far as to remove it, so I`m -0. What happens to issues we discuss/tackle, but don`t manage to finish/implement them on time? Do we throw them back into the sea (instead of putting them aside for 'Future')? Thanks, Eduard On Wed, Oct 3, 2012 at 6:44 PM, Vincent Massol <vincent(a)massol.net> wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On Oct 3, 2012, at 6:49 PM, Marius Dumitru Florea < mariusdumitru.florea(a)xwiki.com&gt; wrote: The problem is not the meaning; we understand why we introduced it... Can you explain to me how you've been using it? If you check current stats you'll see some marked "future" and the vast majority not scheduled. The reason is that we're not using it and honestly I have no clue how to use it properly because once you mark one as future what do you do with it? I imagined that, before Roadmap meetings for the next release/cycle, you

And since we don't have more visibility than the current release there's no way to decide further than that if it's planned for the current release then we set the fixfor for the current release... Thanks -Vincent wrote: that -0. (instead wrote: were _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On Wed, Oct 3, 2012 at 9:23 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: go trough the (publicly available) list of issues marked as 'Future' and consider them to be high priority since they are in the "queue". If you did not do that until now and do not plan to do it, then sure, it's useless.

How else do you/we keep track of important issues across time/versions?

I don`t imagine that a personal list would be the solution for the whole (public) open source project. The current approach (with the 'Future' marker) still seems to me to be an uncomplicated solution to this problem. I don`t even feel the need for the NEW and OPEN markers as Sergiu suggested, since we have "In Progress" and "Future" to differentiate between actively or "passively" working on an issue. Also, there is the "Assigned" field that represents the fact that a *committer* is engaged to fix the issue (can be at his own will) and there is the 'Future' version that represents that the *community/project* is engaged in fixing the issue as soon as possible, even if there is currently no assigned committer. Without such a marker, our reporters might get a sense of abandonment if they see no activity on their issue. Anyway, that's all I had to say on the matter. Maybe your experience with issue/roadmap management is more likely to be correct compared with my above judgement.

Thanks, Eduard > And since we don't have more visibility than the current release there's > no way to decide further than that if it's planned for the current release > then we set the fixfor for the current release... > > Thanks > -Vincent > >> Thanks, >> Marius >> >> On Wed, Oct 3, 2012 at 7:29 PM, Eduard Moraru &lt;enygma2002(a)gmail.com&gt; > wrote: >>> I don`t know, for me it`s good to be able to see which issues are in our >>> "queue", besides the great sea of not yet processed issues :) I agree > that >>> we don`t use it much, but I would not go as far as to remove it, so I`m > -0. >>> >>> What happens to issues we discuss/tackle, but don`t manage to >>> finish/implement them on time? Do we throw them back into the sea > (instead >>> of putting them aside for 'Future')? >>> >>> Thanks, >>> Eduard >>> >>> On Wed, Oct 3, 2012 at 6:44 PM, Vincent Massol &lt;vincent(a)massol.net&gt; > 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? >>>> >>>> Thanks >>>> -Vincent

On Oct 3, 2012, at 10:00 PM, Eduard Moraru &lt;enygma2002(a)gmail.com&gt; wrote: wrote: honestly future did Actually it would be cool if JIRA allowed to add personal labels (i.e. labels that only you can see). That would allow to keep your own list of issues you've reviewed for example.

-Vincent an the a there currently release our I`m like _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On 10/03/2012 11:44 AM, Vincent Massol wrote: 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

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.

Marking issues for which there is some progress should be done by marking them as inprogress.

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.

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

Thanks -Vincent On Oct 3, 2012, at 8:34 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: > Hi Sergiu, > > On Oct 3, 2012, at 6:52 PM, Sergiu Dumitriu &lt;sergiu(a)xwiki.com&gt; 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 >

+1 we don't use it, if we really want an alternative we can always discuss it later

like to propose to remove it. were supposed to use "future" but in practice we are not doing it. -- Thomas Mortagne _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

ok, done. I hope it was "acceptable" for you Marius.

I did it while I entered all the 4.3 dates for all projects. They're now in the JIRA calendar. Thanks -Vincent On Oct 3, 2012, at 5:44 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs