I agree with Edy. For me "Future" means "reviewed and not planned for any time soon". 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

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

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. 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

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Edy, On Oct 3, 2012, at 10:00 PM, Eduard Moraru <[email protected]> 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.

Well, there's no such thing as a "roadmap meeting" in this community ;) All we have is a Roadmap email proposal to which developers respond telling what they want to work on. What I usually do to speed up the process is have an internal meeting with committers who are also part of the XWiki SAS company (since I'm also from XWiki SAS) and get to an agreement to what we wish to work on and in my proposal mail I list stuff we've agreed to work on. The idea is then that other committers not part of XWiki SAS also join in and add what they'd like to work on on their side. From the community point of view, what developers choose to work on is their own choice.

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

We don't have any mechanism for prioritizing our issues and I'm not sure we need one in the community (it would extremely difficult to agree on a metric IMO). Usually open source is about people having an itch to scratch. Now if users want to bring attention of devs to their issues they can do the following: * open a jira issue and kindly ping about it after some time if no progress is made (even better provide a pull request ;)) * vote on a jira issue * send an email to the list and kindly ping about it regularly if no answer is provided * answer to emails about feature surveys * fill the xwiki.org questionnaires * pay someone to work on their issue (we have a professional support section on xwiki.org)

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.

I think the difference is maybe that you seem to feel that we need to prioritize issues. I'm not sure how we would do that (what algorithm?) and even if we did that I'm not sure how we'd "force" committers to implement them in the priority order ;) (and if they don't then the priority order doesn't mean much). Now if you have some ideas please bring them on! I'm sure we can improve what we're doing :) Thanks -Vincent

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

On Wed, Oct 3, 2012 at 11:31 PM, Vincent Massol <[email protected]> wrote:

On Oct 3, 2012, at 10:00 PM, Eduard Moraru <[email protected]> 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.

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.

I think you could do that by using the "Watch" feature on issues you`re interested in (have reviewed). Then you can do a query like: "resolution = Unresolved AND watcher in (currentUser())" and see all the issues you`ve "reviewed". I did not find an UI alternative to get this list of issues :) Thanks, Eduard

-Vincent

...

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 <[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

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

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

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/

On Thu, Oct 4, 2012 at 9:09 AM, Thomas Mortagne <[email protected]>wrote:

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

+1, same as Thomas On Wed, Oct 3, 2012 at 5: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

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

On Sat, Oct 6, 2012 at 7:34 PM, Vincent Massol <[email protected]> wrote:

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

Yes, it's fine :) Thanks, 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 <[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

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs