On 10/03/2012 04:00 PM, Eduard Moraru wrote:
On Wed, Oct 3, 2012 at 9:23 PM, Vincent Massol <[email protected]> wrote:
On Oct 3, 2012, at 6:49 PM, Marius Dumitru Florea < [email protected]> wrote:
I agree with Edy. For me "Future" means "reviewed and not planned for any time soon".
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 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.
Almost any solution for the problem will work, better or worse, but in order for such a solution to work it requires sticking to some rules. The problem isn't that much that the current solution is bad. We haven't been applying the rule consistently, and there are issues marked as Future that we're not putting any effort into, and there are issues that we're considering to have priority but aren't marked in any way. In short, we're terrible at following this rule, so we're just proposing to remove it since it doesn't bring any _perceived_, _real_ value. The alternative is to decide that we do want to follow this rule, like we do with other stricter rules, but this will require time and discipline from all the committers.
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 <[email protected]> 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 <[email protected]> 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
-- Sergiu Dumitriu http://purl.org/net/sergiu/