Comment 1 Alex Blewitt 2007-03-22 20:13:53 EDT

Needless to say, you have my vote.

Comment 2 Mike Milinkovich 2007-03-22 21:12:34 EDT

I think that the real question is how the committers feel about it. If use of these flags really is ingrained in their process, we shouldn't be forcing a change. Just because people are unhappy that their bug isn't getting fixed doesn't change the fact that it is the committer's decision.

In other words, silence from the committer population should not equate approval. We need to see some positive endorsement of this idea from them if we're going to do it. 

So let's hear it, committers!

Comment 3 Chris Aniszczyk 2007-03-22 21:17:34 EDT

+1, in PDE it's only used when Wassim has a hissy fit and closes something as LATER :P At least the good ol' "WONTFIX" is still there :)

btw, people should use those cool flags in the top right of this bug to vote ;)

Comment 4 Matthew Hall 2007-03-22 23:45:26 EDT

Whether or not a universal "Future" milestone is the right approach to take, something really does need to be done about this.  I imagine some of you are tired of hearing this from Alex, but he has a good point.  Too many bugs have been swept under the rug this way.

The possibility for a bug to slip into an eternally indeterminate state just because LATER is a resolution instead of a target milestone is a giant hole in an otherwise very successful community process.

The irony is that RESOLVED LATER acknowledges that the report has some kind of merit (otherwise it would be WONTFIX or INVALID), yet it virtually guarantees that it will never be actually resolved.  Then you add to the mix the fact that anybody else who raises the same issue will have their bug marked as a duplicate of the RESOLVED LATER bug.

Can anyone explain to me what the resistance to this request is?  Why do some committers seem so ambivalent on this issue?

On a side note, I think that regardless of what happens with this bug, it should eventually be marked RESOLVED LATER, just for old times' sake.  :P

Comment 5 David Williams 2007-03-23 02:00:51 EDT

I would prefer you not make any mass changes to bugs ... seems each project (or component) should decide themselves ... though I'm sure your offer to help them make some mass change if they wanted it would be well received. At least, we shouldn't make some mass change until a replacement is we well understood, and agreed to by all. (Which, I hate to say, won't happen any time soon). I believe the strategy be evolutionary ... leave the old resolutions in place, but offer some alternative solutions that committers will find so useful, they'd find it worth migrating. I see the new bugzilla offers "custom resolutions". What about "states"? I think of "remind" as "awaiting more information" (which is more like a state, than a resolution ... you know, it is still 'open', but back in originators hands). I think of "later" similarly as still open, but no one is going to do anything about it anytime soon ... and, that decision was carefully thought out and decided. Whereas, honestly, 80% of the untargeted ones also will have no action any time soon ... but, no one has even thought about those enough to say 'later'. My prediction is that if you encourage a universal 'future', then tons of bugs will go in that bucket, and it will be confusing because it sounds sort of like a commitment that someone is going to work on it some time. Perhaps there should be a state, or target, named "not planned", which better emphasizes the "help wanted" nature of many 'later' resolutons? 

BTW, maybe you can't tell, but I too do not like 'later' as a resolution. Perhaps with custom resolutions (and states, if that's possible) that some projects will come up with and document some more meaningful workflows. 

But, above all, let's let it evolve. 

Comment 6 Nick Boldt 2007-03-23 02:37:58 EDT

(In reply to comment #5)
> projects will come up with and document some more meaningful workflows. 
> But, above all, let's let it evolve. 

Like, for example, bug 149692, which asks for a RELEASED state? 

Comment 7 Gunnar Wagenknecht 2007-03-23 02:48:17 EDT

To be honest, we have some REMIND/LATER bugs in Planet Eclipse. But I agree, they are all better expressed as ASSIGNED with a milestone FUTURE. But that might not be true for all bugs in Eclipse Bugzilla. Sometimes LATER means DONTWANTTOFIX and sometimes REMIND needs NEEDMOREINFOFROMREPORTER. 

So what should we do? I think we need to find some suggestions for the common cases. For example, NEEDMOREINFOFROMREPORTER could be handled via a WORKSFORME or INVALID and DONTWANTTOFIX could be a WONTFIX with a HELPWANTED keyword. But then we need to educate the community that WONTFIX doesn't mean "this will never be fixed".

However, mass changing all bugs could be problematic especially across components and teams. Maybe we should do it the Bugzilla way by using queries and then the mass edit functionality. This way we don't destroy the history and make sure that all interested parties are notified.

Comment 8 Stefan Langer 2007-03-23 05:01:25 EDT

(In reply to comment #7)
I agree with you that there are states that are currently expressed with LATER or REMIND that need to be addressed but the solution to put them in the LATER or REMIND state is no solution because of the implications this has on the bugs. 

The important part here is that a bug that gets put in the LATER or REMIND state cannot be reoopened by someoneelse except for the reporter or committer and so any future development of that bug is likley to be cancled out due to the duplicate bug problem. 
Quite frankly I think this is a very disturbing fact which in my eyes hurts the transparency of the project as a whole. 
I don't care how the solution to this problems works as long as the solution does not cause bugs to slip off the agenda just because they can't be solved right now or because the author needs more information or does not have the time to work on them. I would even accept the LATER and REMIND states if they could be changed by other bug reporters to REOPNED when they report the same bug again.
BTW if you do not have enough information on a bug I'd go with invalid and a comment explaining why the bug is invalid. This way when a bug gets raised again it won't fall to the dreaded mark duplicate and forget about it syndrom (at least in theory :) ) 

Comment 9 Dani Megert 2007-03-23 05:07:34 EDT

I agree with David's comment 5 and also think we look at two different problems here:

1) the REMIND resolution which has different meanings in different components: the text components for example set bugs to REMIND which cannot be reproduced or wait for more information from the reporter. So, if you mass change these bugs to either NEW or INVALID you destroy valuable information. This is a no go.

2) LATER: I really do not see a benefit when those get reopened with a milestone saying 'future' - well it might sound better but it would turn out to be exactly the same.

Also - did anyone think about the work load this change would put on the inbox owner of each component and how many e-mail notifications that will generate when they simply move all those bugs to INVALID? And hence the cost of such a change?

So, a sound -1 from my side to automatic mass change of all bugs in all components. And unless there is a solution/replacement for REMIND I'm also against removing this.

Comment 10 Alex Blewitt 2007-03-23 05:07:56 EDT

(In reply to comment #2)
> Just because people are unhappy that their bug isn't getting fixed
> doesn't change the fact that it is the committer's decision.

Mike, just to clarify -- I could not care less whether such a bug is open until
the Eclipse foundation finally closes its doors for the last time. This is
*not* about complaining whether such bugs are getting fixed or not. This is
purely about whether or not they show up when you search for open bugs. Many
open source projects have long-lasting open bugs.

The point is that a release does not imply that the open bug count has to be
zero by hiding bugs under the covers. It is more likely that you'll get help --
especially with the 'helpwanted' keyword -- if the bugs show up as being in one
of the open states than if they're in one of the closed states.

Alex.

Comment 11 Dani Megert 2007-03-23 05:17:53 EDT

I see the point from comment 10.  Can bugzilla be customized in a way that we can set bugs to ASSIGNED/NEW + LATER/RESOLVED? If not, I doubt that custom resolutions as suggested in comment 0 would address/fix comment 10 as those bugs would be marked as RESOLVED (+ custom resolution) as well and hence not appear in the search for open bugs.

When I set a bug to REMIND (or LATER) it's really not my goal to have it out of my way and get it RESOLVED it's just the only way I can set the REMIND/LATER state. So, I guess the 'Future' target milestone would indeed be a solution/replacement for the LATER issue.

Comment 12 Jerome Lanneluc 2007-03-23 05:30:46 EDT

Totally agree with Dani

Comment 13 Philipe Mulet 2007-03-23 06:00:51 EDT

Also 100% agreement with Dani here.

Comment 14 Martin Aeschlimann 2007-03-23 06:01:23 EDT

I support David's approach in comment 4.
Replacing LATER and REMIND with a milestone 'Future' isn't good enough.

- We need a state 'Remind' for bugs where we need more user input, or need a second occurrence of that problem.
- We need one or more states to sort open bugs so we can handle the load of bugs into bugs we might do and bugs that we are very unlikely to do, but where maybe some external contributer might jump on ('help wanted'). 
- State changes (reopening) by users should only be possible for 'fixed' bugs which turn out to not be fixed. But actually, creating a new bug and mentioning that fact in the old bug is even better. 

Comment 15 Magnus Melin 2007-03-23 06:51:36 EDT

Agree on removing them! Why not just use a keyword for bugs where more user input is needed? Or even use the status whiteboard...

Comment 16 Dani Megert 2007-03-23 07:01:27 EDT

>Agree on removing them! Why not just use a keyword for bugs where more user
>input is needed? Or even use the status whiteboard...
Because I don't want them to lurk in my inbox as assigned/new. It would be fine if you could move them back to UNCONFIRMED but that's currently not possible.

Comment 17 Magnus Melin 2007-03-23 07:07:19 EDT

WORKSFORME would also seem appropriate for such bugs...

Comment 18 Ismael Juma 2007-03-23 07:42:08 EDT

Just FYI, many bugzillas have a NEEDINFO status that is equivalent to the RESOLVED/REMIND being talked about here. 2 examples are the Gnome and Red Hat ones.

Comment 19 Steve Northover 2007-03-23 09:17:07 EDT

+1

Remove the !@$#!$#^%$^#$% useless things.  In my mind, there are only 3 states: fixed, wontfix and open.

Fixed - we fixed it!
Wontfix - we thought about it and decided not to fix it (not a bug, crazy feature request, etc).
Open - it's a real bug (could be serious, could be trivial)

Comment 20 Steve Northover 2007-03-23 09:19:11 EDT

... sigh ... forgot worksforme.  I suppose that could be a kind of wontfix.  Anyhow, I'd be happy if LATER and REMIND were removed.

Comment 21 Denis Roy 2007-03-23 09:56:26 EDT

Here's my unqualified summary of the state of affairs:

1. Committers need to keep their 'open bugs' lists clean. Something that can't be done in the foreseeable future needs to go to a bucket somewhere, and this bucket is REMIND and LATER.

2. The community feels that the REMIND and LATER bucket is, in reality, NEVER.

So perhaps the real issue here is not the actual existence of these resolutions, but that bugs within tend to be forgotten, as Alex has pointed out in the RESOLVED/NEVER saga.

SOLUTIONS
=========

a) all committers use Bugzilla the No-Bull Northover Way. This way, eventually, there won't be anything left in REMIND and LATER, so we could delete them. Lots of committers already use Bugzilla this way anyway. This requires teams to change their process.

b) I design some way to automatically comment on or reopen bugs that are in the REMIND/LATER state after X days/months. This will avoid bugs from disappearing to LA LA LA LA land, and eventually, committers will realize that REMIND/LATER doesn't mean NEVER.


As a side note, I aim for a) on a daily basis, but I just ran a query on REMIND/LATER bugs for infratructure/website and discovered 12 that I had totally forgotten about.  b) would have avoided this problem.

Comment 22 Matthew Hall 2007-03-23 10:28:50 EDT

I like Denis' proposal, as it addresses the problem going forward without creating a huge queue in everybody's inboxes.  My question is in the case of bugs already resolved as LATER or REMIND, what approach could we as a community take to help resurrect the ones we find most important?  If the original reporter has given up, a bug has no possibility of being reopened, and the resolved duplicate problem still exists and is likely to continue.  Do we just ping these bugs with new comments?

Comment 23 Denis Roy 2007-03-23 10:33:32 EDT

(In reply to comment #22)
> My question is in the case of
> bugs already resolved as LATER or REMIND, what approach could we as a community

All of those older bugs would be either commented on or reopened automatically if we decide to implement solution b) in comment 21. The idea here is that the community shouldn't need to REMIND committers, hence the automation.

Comment 24 Michael Valenta 2007-03-23 11:23:02 EDT

Personally, I don't mind if LATER and REMIND disappear as longs as there are suitable replacements. For REMIND, we need a way to put a bug in a state where it says that there is not enough data on the bug and nothing can be done until more information is provided. After a suitable amount of time, such bugs should not be reopened, they should be closed with a message reiterating that the reporter failed to provide enough information. 

The LATER case is more complicated since the state means different things to different teams. Some teams still actively use the state while others tried it for a while, realized it wasn't helpful but don't want to do a mass reassign because of the e-mail spam and lack of suitable alternative.

To give a specific example, for my component, I would be happy if the bugs were moved to the ASSIGNED state and the assignee changed to the component mailbox. This would work for me since I use the NEW and REOPENED state against the component inbox to represent untriaged bugs. I would also like a message to be added explaining to the interested party what just happened and why. I can;t do this myself since the mass bug change form of bugzilla doesn't support a transition from RESOLVED/LATER to ASSIGNED.

Unfortunately, I suspect that the approach I outlined may not work for other teams but they'll have to speak for themselves.

Comment 25 Jerome Lanneluc 2007-03-23 11:32:31 EDT

Another way to see a bug assigned with the LATER state is that it is a bug that was given low priority by the committer. So if LATER was to be removed, I would like the corresponding bugs to be given a P5 priority.

For a replacement of REMIND, I would vote to move the corresponding bugs to the UNCONFIRMED status.

Comment 26 Dave Orme 2007-03-23 12:05:52 EDT

(In reply to comment #21)
> SOLUTIONS
> =========
> ....
> b) I design some way to automatically comment on or reopen bugs that are in the
> REMIND/LATER state after X days/months. This will avoid bugs from disappearing
> to LA LA LA LA land, and eventually, committers will realize that REMIND/LATER
> doesn't mean NEVER.

+1 for auto-commenting after a period of time.

The extra email periodically
would guarantee that I don't forget bugs I've put into Resolved/NEVER er LATER.
;-)

Comment 27 Denis Roy 2007-03-23 17:04:45 EDT

This simple SQL statement pulls out RESOLVED/REMIND and RESOLVED/LATER bugs where there has been no comment for 6 months. 6006 bugs match, and I've posted the older ones below.  Obviously, we could run this every day and post a comment, hence resetting the 'nagging' for another 6 months for th.

SELECT 	BUG.bug_id, MAX(COM.bug_when) AS LastComment
FROM 	bugs AS BUG
	INNER JOIN longdescs AS COM ON COM.bug_id = BUG.bug_id
WHERE 	BUG.bug_status="RESOLVED" 
    AND BUG.resolution IN ("REMIND", "LATER")
    AND COM.bug_when < DATE_SUB(CURDATE(), INTERVAL 6 MONTH)
GROUP BY BUG.bug_id
ORDER BY LastComment DESC;

Oldest bugs that match the query:
+--------+---------------------+
| bug_id | LastComment         |
+--------+---------------------+
|   3186 | 2001-10-11 09:17:20 |
|   3850 | 2001-10-17 09:27:07 |
|   4182 | 2001-10-18 10:27:38 |
|   5076 | 2001-10-19 07:54:01 |
|   3178 | 2001-10-23 23:50:44 |
|   3201 | 2001-10-23 23:51:23 |
|   3286 | 2001-10-23 23:53:59 |
|   3180 | 2001-10-24 06:17:43 |
|   3184 | 2001-10-24 06:18:18 |
|   3495 | 2001-10-25 11:38:59 |
+--------+---------------------+

Comment 28 Alex Blewitt 2007-03-23 18:22:33 EDT

I would suggest that if you are unable to reproduce a bug because of a lack of info then RESOLVED WORKSFORME or RESOLVED INVALID are two good solutions. You can then add a comment to the effect that you are unable to reproduce the bug, or that the bug does not contain enough information, and put the onus back on the original reporter to provide more details. This should be the state for bugs where there's not enough information; it says that no further work is done until the original submitter submits more information. If it's a relatively newish bug, then the reporter is likely to come back and add the information -- and if they don't, hey, it's an invalid bug that gets closed.

If someone raises a duplicate bug, then it should not be marked as a duplicate of a RESOLVED WORKSFORME/INVALID bug. It's quite possible that the newly reported bug has better or more detailed information, or even that it's been reported against a different version (where a function may have regressed).

If a bug is real, but it just can't be done now (say, the public API is frozen or whatever) then it should be left open (i.e. NEW or ASSIGNED) with a milestone of later.

From a triaging perspective, this is the purpose of the bugzilla state UNCONFIRMED. If newly filed bugs start with an UNCONFIRMED state, then the stuff-to-process becomes the set of UNCONFIRMED bugs. Once it's been deemed that it's a real bug (or whatever the triage requirements are) then it gets moved into the NEW state; see the bugzilla chart:

http://www.bugzilla.org/docs/tip/html/lifecycle.html

One could imagine having UNCONFIRMED as being the newly-filed inbox, with NEW being open (but not assigned; bugs where there are no plans to fix, help wanted and/or simply filed against a future version could have a Later milestone or a keyword such as 'helpwanted') and then ASSIGNED as the set of things that committers are currently working on. If a bug needs to be put on hold, it could easily be moved back to NEW (i.e. still open, but not in the UNCONFIRMED incoming triage list) with an appropriate keyword.

Re: mass spam of e-mails for changing. Either there would be a mass spam (if it were done through Bugzilla) or if done via SQL udpates there would be no such spam. I'd imagine that the right approach for each team could be decided and the appropriate choice made. However, this should be viewed as a one-off hit to fix this problem, and not the sole reason for not doing it.

Comment 29 Alex Blewitt 2007-03-23 18:51:05 EDT

NB the Priority field is also something that can be used to filter items. If priority 5 is least important, any bugs that Martin/Dani don't want to see can be flagged as priority 5; their queries can then only view priority 1-4. AFAIK the priority field is something that only committers can change anyway, and if it's deemed in such a state that they don't have time/inclination to process it at that time, lowering the priority is a way of allowing them to be filtered out whilst still leaving the bug in an open state for others to see.

Of course, if there were no open 1-4 priority bugs, then that would leave these least important ones as the only ones open -- but there's no such thing as bug free software, and I don't see that happening :-)

Martin/Dani, would that be something you could use?

Comment 30 Dani Megert 2007-03-24 06:54:18 EDT

For me REMIND provides more info than just INVALID or WORKSFORME: it also says we'll there's probably a bug but we don't know enough yet. When I get new bugs which aren't clear I search the REMIND bucket. so I would rather replace REMIND with UNSPECIFIED and get the new bugs into the new-bucket. This way I know the bugs in each bucket have a clear meaning: 'new' really means those are the new bugs, ASSIGNED means I looked at it and it is accepted and UNSPECIFIED there's missing info to tell more about this bug. If new bugs would end up directly in UNSPECIFIED we'd have a mix of processed and unprocessed bugs - not something I would want.

Moving the LATER bugs to ASSIGNED with target milestone 'future' or 'later' is fine as it allows to search all open bugs at once.

Comment 31 Alex Blewitt 2007-03-24 16:19:01 EDT

(In reply to comment #30)
> For me REMIND provides more info than just INVALID or WORKSFORME: it also says
> we'll there's probably a bug but we don't know enough yet. When I get new bugs
> which aren't clear I search the REMIND bucket. so I would rather replace REMIND
> with UNSPECIFIED and get the new bugs into the new-bucket. This way I know the
> bugs in each bucket have a clear meaning: 'new' really means those are the new
> bugs, ASSIGNED means I looked at it and it is accepted and UNSPECIFIED there's
> missing info to tell more about this bug.

This sounds pretty much like the ordinary Bugzilla status, but with a mapping:

NEW->UNCONFIRMED
UNSPECIFIED->NEW
ASSIGNED->ASSIGNED

The 'UNCONFIRMED' state (which is standard Bugzilla, as opposed to UNSPECIFIED which isn't) is the one that all newly-created bugs go into. It's just that instead of new bugs being NEW, they'd be UNCONFIRMED. They'd only move out of UNCONFIRMED once someone's looked at them and confirmed them (or marked as RESOLVED INVALID if there's not enough information to reproduce).

But it sounds like there's progress towards getting rid of LATER and replacing it with a milestone; Martin, do you agree?

Alex.

Comment 32 Jason Bennett 2007-03-25 14:57:39 EDT

Does anyone think that RESOLVED/LATER leads to more dup reports? I believe that the standard Bugzilla search will not turn up those bugs, leading people to re-file them. Any solution should try to take this into account.

Comment 33 Steve Northover 2007-03-25 18:55:36 EDT

Jason is correct.  Any categorization that filters out real or potential problems in a search is not helpful.  That's why I don't use these categories.  They lead to duplicates.

For me, there is no shame in an open bug, even one that has been open for a while.  We have limited resources and can only address so much.  An open bug captures an issue, the history of what people have tried, who has been affected, work arounds, the discussion, patches ... the list goes on.

Sometimes bugs are used by "blog mouths" to try and discredit a project but real programmers know that software has bugs and it's better to track as many as possible, rather than pretend they don't exist.

(I can't believe we actually might be getting rid of these things ... somebody pinch me)

Comment 34 Dani Megert 2007-03-26 03:14:19 EDT

>The 'UNCONFIRMED' state (which is standard Bugzilla, as opposed to UNSPECIFIED
>which isn't) 
Sorry, I meant UNCONFIRMED. No need for yet another state ;-)

> They'd only move out of
>UNCONFIRMED once someone's looked at them and confirmed them
The drawback with this is that if I look at an unconfirmed bug and then don't promote it to NEW I loose the information that I looked at that bug already since it still sits in the UNCONFIRMED box, while if all bugs would come in as NEW and I could then either set it to ASSIGNED or UNCONFIRMED I would not loose it i.e. NEW means no one looked at them yet. ASSIGNED means the bug is accepted and UNCONFIRMED means the bug has been looked at but needs clarification. Note that currently bugs for the Eclipse project come in directly as NEW and not UNCONFIRMED.

Comment 35 Stefan Langer 2007-03-26 03:38:12 EDT

(In reply to comment #33)
> [...]
> For me, there is no shame in an open bug, even one that has been open for a
> while.  We have limited resources and can only address so much.  An open bug
> captures an issue, the history of what people have tried, who has been
> affected, work arounds, the discussion, patches ... the list goes on.
> 
> Sometimes bugs are used by "blog mouths" to try and discredit a project but
> real programmers know that software has bugs and it's better to track as many
> as possible, rather than pretend they don't exist.
> [...]
This is exactly what I mean with my statement about transparency. I think it is of great importance to do the bug processing in the open as far as possible and report open bugs as such. And if a "blog mouth" discredits the project hey just give em the "Then FIX it yourself smart a..." line. I think it is one of the keys to making the eclipse ecosystem better and show the community that there is an effort to solve each bug and not hide it away. 
One thing I read in this bug so far is that everyone agrees that the REMIND/LATER states are a problem the only thing that isn't confirmed yet is how the problem is to be solved. Am I correct?

Comment 36 Alex Blewitt 2007-03-26 04:00:47 EDT

(In reply to comment #34)
> > They'd only move out of
> >UNCONFIRMED once someone's looked at them and confirmed them
> The drawback with this is that if I look at an unconfirmed bug and then don't
> promote it to NEW I loose the information that I looked at that bug already
> since it still sits in the UNCONFIRMED box, while if all bugs would come in as
> NEW and I could then either set it to ASSIGNED or UNCONFIRMED I would not loose
> it i.e. NEW means no one looked at them yet.

Please look at the standard Mozilla bug lifecycle:

http://www.bugzilla.org/docs/tip/html/lifecycle.html

UNCONFIRMED is used to denote a newly reported bug by the front-end user interface (i.e. one that no-one's looked at yet, and what is currently thought of as NEW). It only moves from UNCONFIRMED->NEW if it has been confirmed that it exists.

One of the reasons for raising this bug is that we're attempting to fix the bugzilla process i.e. move it towards standard bugzilla guidelines. Swapping the meaning of NEW and UNCONFIRMED will not help this.

It strikes me that if you leave a bug in the UNCONFIRMED state, then it is still UNCONFIRMED. The goal would be (I hope) to not have many in the UNCONFIRMED state, since it's purely transitional on the way to NEW (i.e. it is a bug) or RESOLVED INVALID (if there's not enough information). If you don't have time to process it then, it's still in the bug inbox for next time.

Alex.

Comment 37 Bryan Hunt 2007-03-29 12:23:17 EDT

I tend to agree with Steve's position.  Our legacy defect tracking system has exactly three states: Open, Answered, Closed.  From a user's point of view, it's nice to have a simplified view of bugs.  From a developer's point of view, I can see how it's necessary to have additional information to help manage the bugs.

Here's my personal view as an understaffed plug-in developer ...

I have a problem, is there an open or resolved bug?  Open: add myself as an interested party, and when can I expect the bug to be fixed.  Resolved: which build can I download to get the fix.  None: create a new bug, code a workaround, and wait for it to be resolved.

I hope that a solution can be found that is accomidating to both roles.

Comment 38 Konstantin Komissarchik 2007-03-29 12:36:06 EDT

+1 LATER/REMIND resolutions have effectively become identical to WONTFIX

Comment 39 Bjorn Freeman-Benson 2007-03-29 12:39:35 EDT

I'm fine with REMIND and LATER, but not with them being associated with
RESOLVED. So if the choice is RESOLVED/LATER or not, I go with not. If we could
have an OPEN/LATER, that would be even better.

Comment 40 Philipe Mulet 2007-03-29 12:45:50 EDT

Our team is using REMIND when the bug assignee has requested more information from the reporter, and didn't get it in a long time. Until the info is supplied, no progress can be made. Usually a bug remains in REMIND mode for a while (~6 months) before it times out. 

This could be expressed differently; but we should have a way to find these and not mix them with others. For us, a bug in REMIND state is to be looked at by the reporter (who we ask to reopen once the information has been supplied).

I have no strong opinion for LATER. It feels that no milestone is equivalent to a future milestone; likely if for LATER, then simply low priority is good enough.

Comment 41 Olivier Thomann 2007-03-29 12:47:44 EDT

I think we need a way to express:
- bugs that are not intended to be fixed within this cycle => actual RESOLVED/LATER
- bugs that need more input to be investigated => actual RESOLVED/REMIND at least for the JDT/Core team. When something is not reproducible and more input is required, there is no point to see those as NEW or OPEN bugs since nothing can be done as is.

So removing these two resolutions is ok as long as we have a replacement for the two items above.

Keeping all bugs as NEW is overwhelming and we actually lose tracks of the important ones. Maybe we should better use the priority value.

Comment 42 Darin Swanson 2007-03-29 12:58:48 EDT

I will be fine with whatever is decided here...I have no strong feelings.
My comments:
  - the community must not have the expectation that more bugs will get fixed just  because of this change

 - if a reporter forgets about a bug, is it really that much of a problem?

 - the change must not have a negative impact on teams that are doing excellent bug triage such as JDT

Comment 43 Tod Creasey 2007-03-29 13:30:09 EDT

-1 this is an important way for us to be transparent to the community about what is being actively looked at.

REMIND is used like MORE_INFO for us - we can't proceed until we know more.

Bymarkin a bug LATER it is clear that it is not on plan - we get tons of "will this be in realease x" comments. For the very busy teams like Platform UI this will make it even harder to keep track of things,

Bjorn suggested Open LATER/REMIND - that would be fine for me.

Comment 44 John Arthorne 2007-03-29 13:37:20 EDT

+0. After thinking about this, I'm indifferent. I have experimented with using these resolutions in the past, but in retrospect they have not been useful.

For bugs that lack sufficient information, I now mark them as INVALID rather than WONTFIX.  The distinction between these two states was not particularly useful to me during bug management.  Also, INVALID is actually a much better indication to the originator that the ball is back in their court, and they need to provide more information and reopen the bug.  REMIND was unclear in this way - who is being reminded, the originator or the component owner? This may have been clear to us, but likely not to the community.  Bugs that lack sufficient information to act upon them are not valid bugs, so this resolution fits nicely.

For bugs/enhancements that no committers intend to fix in the forseeable future, I now mark them WONTFIX. Again, this communicates to the originator that unless they argue their point better, or provide assistance in addressing it, that no action will be taken. Bugs that are valid and may be addressed time permitting are left open and assigned to the inbox with corresponding priority.

I vote +0 because even though I don't find these states useful, I see no reason to remove them if they are useful to other bugzilla users.

Comment 45 Anthony Hunter 2007-03-29 14:12:38 EDT

RESOLVE/REMIND:
-1

(In reply to comment #43)
> -1 this is an important way for us to be transparent to the community about
> what is being actively looked at.
> REMIND is used like MORE_INFO for us - we can't proceed until we know more.
> Bymarkin a bug LATER it is clear that it is not on plan - we get tons of "will
> this be in realease x" comments. For the very busy teams like Platform UI this
> will make it even harder to keep track of things,

I agree with Tod, we make use of RESOLVE/REMIND especially when looking at old Bugzillas.

"You raised XXX in 2.1 and in 3.3 we now have YYY, is XXX still an issue?"

> Bjorn suggested Open LATER/REMIND - that would be fine for me.
+1 ditto, we do not use RESOLVE/LATER

Comment 46 Alex Blewitt 2007-03-29 19:06:24 EDT

Re: comment 39: bugzilla has states (UNCONFIRMED), NEW, ASSIGNED, RESOLVED, VERIFIED, CLOSED. There is no 'sub-state'. However, there is a 'resoution status' of e.g. WONTFIX/INVALID.

The point is, there is no 'OPEN/*' state in Bugzilla, because if it's not resolved, it doesn't have a resolution state. You don't get to classify bugs in that way, though there is the otherwise unused UNCONFiRMED state that could play a part.

Re: comment 40: rather than RESOLVE REMIND, just RESOLVE INVALID. That way, it's up to the bug reporter to re-open with the requested information. You don't need to keep track of time for them to provide something; the requestor (or someone on the list) is responsible for getting the bug back into circulation, not you. Furthermore, there should never be duplicates of a RESOLVE INVALID, because each bug should be considered on its own merits.

Re: comment 43: "this is an important way for us to be transparent to the community about
what is being actively looked at." The community has spoken that they don't want bugs to be hidden in this way. The volume of votes (both comitter and non-commiter) clearly marks that we *don't* want this to occur. Get rid of bugs that you can't reproduce with RESOLVE INVALID (and ask the reporter to re-open with more info, or whatever, and if they don't, it's out of the picture) and keep the bugs that you have no plans as NEW or ASSIGNED with a low-priority (P5) milestone of LATER, which is plenty enough to tell us you have no further interest in working on the bug. Heck, use 'helpwanted' or some other keyword, but don't hide them. Can the community be any clearer?

My proposal:

RESOLVE/REMIND -> RESOLVE/INVALID with a comment to re-open with the requested info etc. (and/or simply 'if this is still a problem on the most recent release') to get them out of the picture

RESOLVE/LATER -> NEW or ASSSIGNED with a priority P5 and a target milestone of LATER, with a keyword 'helpwanted' and/or 'later' 

This would be clear enough what the intent is (and let's not forget, there's a lot of bugs left that are open that aren't being looked at either; the 'helpwanted' is a way of asking for help outside the committer base. That's pretty clear.

Comment 47 Pascal Rapicault 2007-03-29 21:21:37 EDT

To me those resolutions are ways for committers to prioritize their bugs and
organize their work. Bugzilla should be tailored for people doing the actual
work, committers, and should make it possible for community members to
navigate. 
To that end I don't think we should remove any state, in fact I would vote for
giving the ability to the committers to add as many state as they want if it
helps them being more productive! In the end that's the only thing that
matters.

So just to be clear, I'm not trying to hide bugs, I just want my inbox to be
manageable, and I also want to make sure that the request I do to bugzilla
comes back in a timely fashion (on RC days bugzilla often choked in the past,
so what if we now all have gigantic lists).

Now if you change states so that bugs are visible, what will happen? I will
change my queries to filter those bugs out of my result lists. Who does that
really help, well I'm not sure. 

If the goal of all that is to make the community aware of where work can be
done, then why don't we put together a page on the wiki where each project can
post a bugzilla query identifying where people can help.

Also, when bugs are moved into a LATER or REMIND state and noone protest, it is
really that the bug is not sooo important. If it was so important it would have
been reopened or someone else would have had the same need therefore creating a
ismilar bug.

Now if the removal of the state wins I would like it to be done without any
massive spam. In fact I think everyone would appreciate if the foundation could
do that completly transparently. Also I would *not* want that to happen before
Europa.

Re comment #27, the request is not correct (and I don't know how to fix it)
since the first bug being returned has been fixed by another bug later (see
last message of bug #3186).

Comment 48 Maxime Daniel 2007-03-30 03:43:20 EDT

(In reply to comment #46)
> Re: comment 40: rather than RESOLVE REMIND, just RESOLVE INVALID. That way,
> it's up to the bug reporter to re-open with the requested information. You
I would vote against this. INVALID does not quite cut it for us, because we tend to use it only for bugs that complain about *expected* behaviors, be those backed up by the language specification or the documentation of Eclipse. In my understanding, if a bug is closed as INVALID (and remains so), the reporter and the developer came to an agreement (potentially implicit - if I move a bug to INVALID because of my reading of the language spec and the reporter stays silent) that the case reported against is OK. In constrast, cases for which we lack information are at best INCOMPLETE, but potentially darn VALID.

> don't need to keep track of time for them to provide something; the requestor
> (or someone on the list) is responsible for getting the bug back into
> circulation, not you. Furthermore, there should never be duplicates of a
> RESOLVE INVALID, because each bug should be considered on its own merits.
Agreed. If we don't know enough about a bug, we have no serious basis on which we could declare it a dup.

Comment 49 Maxime Daniel 2007-03-30 03:45:04 EDT

(In reply to comment #48)
> I would vote against this. INVALID does not quite cut it for us, because we
> tend to use it only for bugs that complain about *expected* behaviors, be those
> backed up by the language specification or the documentation of Eclipse. In my
> understanding, if a bug is closed as INVALID (and remains so), the reporter and
> the developer came to an agreement (potentially implicit - if I move a bug to
> INVALID because of my reading of the language spec and the reporter stays
> silent) that the case reported against is OK. In constrast, cases for which we
> lack information are at best INCOMPLETE, but potentially darn VALID.
(In reply to comment #7)
> might not be true for all bugs in Eclipse Bugzilla. Sometimes LATER means
> DONTWANTTOFIX and sometimes REMIND needs NEEDMOREINFOFROMREPORTER. 
I would not like to use WORKSFORME for that either, because WORKSFORME means to me that a reasonable attempt has been made to reproduce the bug, and that the problem did not show up or does not show up any more. The most prominent cases are behaviors that have been fixed in later versions (in which situation I like to report that I could reproduce it with version N but that the same test case succeeded in version N+P), or cases for which I can provide a few concrete test cases that work and seem very close to what the user describes, without getting into trouble. (And also the case of a 'gray' situation in which our documentation leaves some room for interpretation and my interpretation differs from the one of the reporter... but for those I usually prefer to negociate a move to an enhancement request, an INVALID state, or a shift in focus - typically fix the imprecise doc.)

Comment 50 Stefan Langer 2007-03-30 03:49:29 EDT

(In reply to comment #47)
> [...]
> If the goal of all that is to make the community aware of where work can be
> done, then why don't we put together a page on the wiki where each project can
> post a bugzilla query identifying where people can help.
> [...]
This sounds like a good idea that should be addressed in a new enhancement
request.
> Also, when bugs are moved into a LATER or REMIND state and noone protest, it is
> really that the bug is not sooo important. 
Well I do not agree. On certain occasion the reporter accepts that the bug
cannot be worked on right now and that the priority is somewhere else so the
reporter accepts the state. The reporter forgets about it and the bug lies
around not showing up as open. Any future bug will be a duplicate and in a lot
of cases this is equivalent with a wontfix state for no apparent reason to the
community.
>If it was so important it would have
> been reopened or someone else would have had the same need therefore creating > a similar bug.
> [...]
Now this is where the problem lies. The community is not able to find the bug
since it is not open anymore. When you find a new bug you will not likley look
in the resolved section to see if the bug is closed unless you have firm
believe to do so. (Probably a lot of user will when the later/remind states
remain the way they are making looking for a bug a total nightmare) So it is
unlikley that any reporter will find the bug and just create a duplicate. So
again the actual problem is that the later and remind states are resolved
states and not simply open states with an appropriate meaning.

Comment 51 Maxime Daniel 2007-03-30 04:01:20 EDT

(In reply to comment #26)
> (In reply to comment #21)
> > SOLUTIONS
> > =========
> > ....
> > b) I design some way to automatically comment on or reopen bugs that are in the
> > REMIND/LATER state after X days/months. This will avoid bugs from disappearing
> > to LA LA LA LA land, and eventually, committers will realize that REMIND/LATER
> > doesn't mean NEVER.
> 
> +1 for auto-commenting after a period of time.
> 
> The extra email periodically
> would guarantee that I don't forget bugs I've put into Resolved/NEVER er LATER.
> ;-)
> 
Auto-commenting may help to some extent, but *please* do not move bugs back to
NEW automatically. I personally put some efforts into reviewing LATER bugs
periodically to bring forward those that would fit in my current shorter term
plans, and I know why those which stay in LATER are there (potentially since
some time). The last thing I want is to have to move them back to LATER every
month or so.

Now I agree with other comments that a better use of ASSIGNED Future and
priorities could give us more leverage and improve the situation. 

[Elaboration... The very one thing I'd like to have is a way to tell me the why
of the priority (say: P5 because we don't want to refactor such class in 3.3
timeframe), and other refinements about it (e.g. 'attempt to tackle this along
in September...'), on the bugs list page, and also a way to change that without
sending mails to everyone. When I am running a planning pass, one thing that
prevents me to be as  specific as I would like about planning information
(refinements of the Future target, if you will) is that I do not want everyone
to be annoyed (and sometimes even to *know* about it - there is some tension
here: we want to work in the open, but some comments are best kept known by a
few - say 'I would be glad to do it but we've been fighting with XYZ for two
weeks upon the design and we could not strike an agreement and I'm fed up and
I'll come back to it after Summer vacations' ;-)).]

BTW, in the current state of the proposals, I'll cast a -1.

Comment 52 Sebastian Davids 2007-03-30 05:24:14 EDT

I agree with Steve. (comment 19).

Just leave the bugs open if you do not have the time/resources/information to handle them.

FIXED ... bugger's gone

WONTFIX ... if you decide you don't want to handle them and/or if they work as you intend and/or you want help ([helpwanted] flag)

WORKSFORME ... if you cannot reproduce the problem

If you do decide to add an REMIND/LATER state, then all bugs assigned to that state should be automatically put into the OPEN state after a release cycle (i.e. post 3.3, post 3.4, etc.).

Comment 53 Alex Blewitt 2007-03-30 06:08:01 EDT

(In reply to comment #47)
> So just to be clear, I'm not trying to hide bugs, I just want my inbox to be
> manageable, and I also want to make sure that the request I do to bugzilla
> comes back in a timely fashion (on RC days bugzilla often choked in the past,
> so what if we now all have gigantic lists).
> 
> Now if you change states so that bugs are visible, what will happen? I will
> change my queries to filter those bugs out of my result lists. Who does that
> really help, well I'm not sure. 

The problem is that the current RESOLVED * does hide bugs; it's an unintended
side-effect.

If we come up with another proposal (e.g. mark off P5 as effectively 'later'
bugs, or use later keyword, or ...) then you can filter your result lists. Who
it helps is *you*, because you get to see the smaller result set that you want.
It also helps *me* because I don't have those filters, and I can see any of the
open bugs. 

The issue is how do we hide them from you, whilst not hiding them from anyone
else? 

Comment 54 Ed Merks 2007-03-30 07:00:21 EDT

I think using remind as I just did for https://bugs.eclipse.org/bugs/show_bug.cgi?id=179513 is reasonable so I vote -1.
I use a resolution of later rarely and then only for feature requests that I personally would not like to use, would not like to have to support personally, and hence would never use my own or my team's time to implement.  Only if it's really a bad idea, do I return it as wont fix.  

That being said, I could live with changing later to wontfix and changing remind to worksforme.)

Comment 55 Steve Northover 2007-03-30 09:00:26 EDT

+1

Remove the #@$%@#$ things and stop hiding bugs.

Comment 56 Dani Megert 2007-03-30 09:03:39 EDT

I'm in a '?' state. Replacing 'LATER' with a special target milestone is OK for me if that is really felt as an improvement for the community but removing 'REMIND' until there is an acceptable replacement is a -1.

Comment 57 Denis Roy 2007-03-30 09:08:01 EDT

I think Jason raises an important point in comment 32.

I think many of our users do an honest attempt to find an existing bug before opening a new one (and this is especially true with the new bug entry wizard that committers do not see). However, LATER/REMIND bugs are hidden by default, which can lead a user to filing a new bug report (instead of simply commenting or voting on an existing bug).

I think we all agree that any attempt to reduce dupes is a direct gain in productivity -- you can easily recognize a dupe when it comes it, but finding the duped bug is often time consuming.

From Comment 47:
> those resolutions are ways for committers to prioritize

Bugzilla has a Priority field for this. As Alex pointed out, you can toss LATER/REMIND bugs in the P5 priority, and remove P5 from your Inbox search for a small, uncluttered list. No direct benefit for you, but for the general public, P5 bugs will show up in searches, leading to less dupes.

> if the foundation could
> do that completly transparently. Also I would *not* want 
> that to happen before Europa.

Agreed. The goal here is *not* to add burden on committers, so we won't mass-spam or do major changes within the Europa timeframe.

From comment #54
> I think using remind as I just did bug 179513 is reasonable

The problem is that if someone else encounters the same warning, they won't see the bug in a search because it's "hidden", so they'll open a new bug which may waste your time.

Comment 58 David Williams 2007-03-30 09:36:34 EDT

(In reply to comment #57)
> 
> From comment #54
> > I think using remind as I just did bug 179513 is reasonable
> 
> The problem is that if someone else encounters the same warning, they won't see
> the bug in a search because it's "hidden", so they'll open a new bug which may
> waste your time.
> 

Actually, when searching for dup's, "resolved" bugs should always be included, since, after all, it might have been FIXED already. 

So, perhaps the solution here is just improved built-in/default queries? 

Comment 59 John Arthorne 2007-03-30 09:44:39 EDT

I agree with comment #58. If I'm looking for duplicates I would never restrict it to open bugs. Often I'll end up finding a different duplicate, and then follow the links back to the root of the duplicated bug chain.  I really have no idea where this "hidden by default" notion comes from - when I go to the bugzilla query page it doesn't seem to have anything selected by default...

Comment 60 Alex Blewitt 2007-03-30 09:57:01 EDT

Re comment 57; the default bugzilla query doesn't hide them, but people only search for bugs that are open (and therefore select NEW/ASSIGNED manualy). No-one considers searching RESOLVED bugs, because, well, they're supposed to be RESOLVED, and clearly they're still experiencing the bug (as otherwise they wouldn't be raising it). There's really not a lot of point in searching in any of the 'closed states' for bugs, because they're likely to be different bugs maybe with the same wording.

(In addition, marketing comments like 'we resolved 1000 bugs this month' don't mean anything if actually 999 of them are RESOLVE REMIND/LATER.)

Comment 61 Stefan Langer 2007-03-30 10:01:59 EDT

(In reply to comment #60)

In addition the committer has to resolve a duplicate bug that would not have been entered had the original bug shown up on the open bug search

Comment 62 Jerome Lanneluc 2007-03-30 10:07:12 EDT

(In reply to comment #60)
On the contrary, people should always search RESOLVED bugs. For example, let's say I'm using Eclipse 3.2.1. I'm experiencing a bug. I search the RESOLVED bugs and I see that it is fixed in 3.2.2. I just have to update to 3.2.2 and I'm all set. If I hadn't searched RESOLVED bugs, I would report a new one, spend time writing down steps to reproduce and so on.

Comment 63 Maxime Daniel 2007-03-30 10:16:20 EDT

(In reply to comment #62)
> (In reply to comment #60)
> On the contrary, people should always search RESOLVED bugs. For example, let's
> say I'm using Eclipse 3.2.1. I'm experiencing a bug. I search the RESOLVED bugs
> and I see that it is fixed in 3.2.2. I just have to update to 3.2.2 and I'm all
> set. If I hadn't searched RESOLVED bugs, I would report a new one, spend time
> writing down steps to reproduce and so on.
Notwithstanding regressions. A bug that reappears after having been marked as RESOLVED FIXED should be reopened if it comes back in a subsequent I-build.

Comment 64 Denis Roy 2007-03-30 10:26:43 EDT

bug 86343 briefly discusses the default search. I remember setting it to "all bugs" for a while, then realizing searches were taking sooo long that they were slowing down bugzilla. I reverted back to only searching for open bugs (but likely forgot to update the bug), as people were complaining that bugzilla was slow.  

Comment 65 Denis Roy 2007-03-30 10:30:03 EDT

(In reply to comment #59)
> I really have
> no idea where this "hidden by default" notion comes from - when I go to the
> bugzilla query page it doesn't seem to have anything selected by default...

https://bugs.eclipse.org/bugs/query.cgi?format=specific

That's the hidden by default problem, and setting it to "all" has a performance impact on Bugzilla.

Comment 66 Alex Blewitt 2007-03-30 11:54:15 EDT

(in reply to comment 62)

Most people, particularly those that are passionate about Eclipse and willing to invest time in reporting bugs, are going to be running the latest released/milestone version. It's somewhat unrealistic to expect that searching for RESOLVED bugs (or any of the other closed bugs) is going to produce results. The example of 3.2.1 and 3.2.2 is somewhat contrived.

In any case, even if a bug is in 3.2.2 and has been fixed for the 3.3 release, it's still a valid bug against 3.2, regardless of whether it shows up as RESOLVED against 3.3. Whether it's going to be fixed/backported or not is a different matter.

The point is that the set of closed bugs is (hopefully) much larger than the set of open bugs, and if it's already open, there's no point in raising it again. On the other hand, if it's closed, it could be a regression, or against a different version, or a different bug in the same area, or ... 

In any case, the set of recently-resolved-bugs is a very, very small portion of the overall resolved bugs space, so hitting a search for 'resolved bugs' isn't going to bring anything up most of the time (which is (a) why people don't do it -- we've seen that's the case in Eclipse's bugzilla already, and (b) why there are more duplicates of otherwise invisible bugs).

Comment 67 Maxime Daniel 2007-03-30 13:24:08 EDT

(In reply to comment #66)
> (in reply to comment 62)
> 
> Most people, particularly those that are passionate about Eclipse and willing
> to invest time in reporting bugs, are going to be running the latest
> released/milestone version. It's somewhat unrealistic to expect that searching
> for RESOLVED bugs (or any of the other closed bugs) is going to produce
> results. The example of 3.2.1 and 3.2.2 is somewhat contrived.
Perhaps. But searching RESOLVED FIXED is not. If I run the latest milestone instead of the latest I-build, there are hopefully bugs that are not yet in VERIFIED FIXED that I would search before entering a new one. When I write hopefully, I mean it: because we have a vibrant community (and we use Eclipse ourselves), many a user can notice a new breakage at the same time, and if it's a serious breakage, we fix it soon enough to move the bug pretty fast to RESOLVED FIXED. RESOLVED FIXED is not CLOSED in fact. It only means that we have released the change. We could probably run some stats to determine how many bugs get entered that ended up as dups of bugs that were precisely in RESOLVED FIXED state at the time the dup was entered to prove me right or wrong. 

Comment 68 Kent Johnson 2007-03-30 14:06:12 EDT

Denis - is it possible to make the default search scan all RESOLVED/CLOSED bugs modified in the last 60 days + all OPEN bugs ?

This way users can find obvious duplicates without searching all RESOLVED/CLOSED bugs.

Comment 69 Erkki Lindpere 2007-03-31 04:03:44 EDT

How about combining the resolved states in question into RESOLVED/NEVERMIND? j/k :)

Comment 70 Alex Blewitt 2007-03-31 04:52:53 EDT

(In reply to comment #67)
> (In reply to comment #66)
> > (in reply to comment 62)
> > 
> > Most people, particularly those that are passionate about Eclipse and willing
> > to invest time in reporting bugs, are going to be running the latest
> > released/milestone version.
> Perhaps. But searching RESOLVED FIXED is not. If I run the latest milestone
> instead of the latest I-build, there are hopefully bugs that are not yet in
> VERIFIED FIXED that I would search before entering a new one.

Like I said, released/milestone. Many (non-commiter) users don't have the bandwidth to download the latest I builds, which in any case aren't mirrored globally. There's a different use case here for 'what commiters will search for' and 'what external users will search for'. Expecting them to look for the latest release (or milestone release) is likely; expecting them to download the latest I-* build to verify that it's not been fixed yet is not.

> We could probably run some stats to determine how
> many bugs get entered that ended up as dups of bugs that were precisely in
> RESOLVED FIXED state at the time the dup was entered to prove me right or
> wrong. 

Yeah, but you'd find way more RESOLVED DUPLICATE of RESOLVED LATER bugs, which is after all the problem we're trying to solve here. Solving a problem that is likely to affect <10 bugs whilst ignoring a problem that has around 1% of the total bug population is focussing on the wrong area.

Comment 71 Aaron Digulla 2007-04-01 06:26:07 EDT

I'd like to summarize a few points:

- This is an important issue for both developers and users.

- The current system doesn't really for for either. The default settings for users hide bugs, the developers can't really set the states they need ("I'm using WORKSFORME for ...")

- no one except the Bugzilla experts can track bugs the way they want.

I don't know that much about Bugzilla but the magnitude of options in the search screen always worries me. The form says: "Look, if you don't get it, play somewhere else". I liked the quick search which the web team provided but, alas, the quick search never found any bugs, even if I knew they existed. I think there is a reason for that.

In the end, I think the best solution would be to have *two* views on Bugzilla. When I look as a user, I have two goals:

1. I found a bug. Does it already exist?
2. What happened to the bugs I reported/which I'm interested in.

Both is currently possible but hard. When I search for a bug, I deselect *all* options but the search text. This forces Bugzilla to do a full table scan which isn't a problem for *me* :-)

When I need to know what happened to my bugs, I let bugzilla search for anything with my email in it. I've found that's the only way which works. It takes a few minutes to configure the search mask, though, so I guess not many people do it.

From the developer side, it seems hard to prioritize bugs. What a developer needs:

- Find the new bugs or bugs that should be checked again
- Sort them into categories/lists ("I can fix that", "Hand over to someone else", "Need more info", "Remind me when this release is over", "Remind me after M#", "Remind me next week", etc.).

Therefore, I suggest to open a bug against Bugzilla which splits "status" and "resolution" into two distinct, independent states.

"status" is for users: Open, Accepted, Closed (3 states max).
"resolution" (for want of a better name) is for developers: New, Accepted, NeedMoreInfo, Rejected, WorksForMe, RemindAfter(date/plan item), HelpWanted, etc.

The goal should be to allow users and developers to stick to their view of the world. For example, some committers get really nasty when you reopen a bug. As a user, I can't know this nor should I. This is a team/committer-internal issue. On the other side of the coin, the developers should be able to work without being drowned in Bugzilla spam.

Comment 72 Maxime Daniel 2007-04-02 02:03:36 EDT

(In reply to comment #70)
> (In reply to comment #67)
> > (In reply to comment #66)
> > > (in reply to comment 62)
> > > 
> > > Most people, particularly those that are passionate about Eclipse and willing
> > > to invest time in reporting bugs, are going to be running the latest
> > > released/milestone version.
> > Perhaps. But searching RESOLVED FIXED is not. If I run the latest milestone
> > instead of the latest I-build, there are hopefully bugs that are not yet in
> > VERIFIED FIXED that I would search before entering a new one.
> 
> Like I said, released/milestone. Many (non-commiter) users don't have the
> bandwidth to download the latest I builds, which in any case aren't mirrored
> globally. There's a different use case here for 'what commiters will search
> for' and 'what external users will search for'. Expecting them to look for the
> latest release (or milestone release) is likely; expecting them to download the
> latest I-* build to verify that it's not been fixed yet is not.
I do not ask them to download the newest builds. What I mean is that a reporter who is about to  open a new bug should be able to find any bug that his problem at hand might be a duplicate for, and I contend that RESOLVED FIXED bugs are relevant candidates for such a use case.

Comment 73 Martin Aeschlimann 2007-04-02 04:51:07 EDT

-1. I can't vote +1 until I know what's the replacement, and, IMO, we really need a replacement for the two states. I agree that the later/remind should not be in the 'resolved category'

Comment 74 Martin Oberhuber 2007-04-04 14:33:33 EDT

+1
In our project, we are assigning to dsdp.tm.rse-inbox@eclipse.org with target milestone="---" in order to show things that are marked for later. I'd agree that the two states can be removed, although I'd also be interested how other projects handle deferred decisions.

Comment 75 Denis Roy 2007-04-09 11:15:47 EDT

We've gathered some great feedback on this, and although many committers agree that the resolutions should go, a small number have voted -1. Therefore, the LATER and REMIND resolutions will not be removed.

However, as we practically all agree that LATER and REMIND shouldn't be associated with the RESOLVED state, let's all agree to consider their usage as deprecated and obsolete, and consider using solutions from the suggestions below as replacements for LATER and REMIND.


LATER
=====

Solution 1: Use the "---" milestone, leave bug as new.  Remove "---" from your default search criteria for open bugs to keep list short.

Solution 2: Create a new "Future" milestone. Assign later bugs to Future and leave as new. Remove "Future" from your default search criteria for open bugs to keep list short.

Solution 3: Leave bug as new, set Priority = P5. Remove P5 bugs from your default search criteria for open bugs to keep list short.


REMIND
======

Solution 1: Close bug as INVALID if there is missing info. Leave the onus on the reporter to file a valid bug report. Add the 'needinfo' keyword.

Solution 2: Close bug as WONTFIX if you never, ever have the intention of fixing it. Use the helpwanted keyword if you'd accept community support.

Solution 3: Leave as new.  Add 'needinfo' keyword.  Remove keyword=needinfo from your default search criteria for open bugs to keep list short.


I'll update documentation and FAQs to indicate that REMIND and LATER are deprecated and should not be used.

Thanks to everyone for your feedback!

Comment 76 Alex Blewitt 2007-04-09 15:02:30 EDT

NB leaving a REMIND as WONTFIX still puts it in the RESOLVED bucket, and it shouldn't be there either. 

It's also worth observing that those that voted -1 are the ones that use this currently (and, from the looks of things, have the ongoing intention to keep on using them) whilst pretty much everyone else who voted expressed their annoyance at the three of those that are using these states.

So, to summarise: public opinion has had no impact at all on what happens at Eclipse, and even though it's clear that most people want to get rid of them, the people who always used to use them will continue using them. The status quo stands.

Comment 77 Matthew Hall 2007-04-09 17:13:44 EDT

Alex, I'm reading your latest comments on this bug and I'm beginning to lose respect for you.  It doesn't matter whether the issue has merit; you are being undiplomatic and in the end it will hurt your case more than help it.

Comment 78 Steve Northover 2007-04-09 17:26:44 EDT

How about this: LATER and REMIND are deprecated.  What about a warning dialog every time they are used?

Comment 79 Martin Oberhuber 2007-04-10 04:53:05 EDT

(In reply to comment #75)
Denis - thanks for your great summary of alternatives to be used instead of LATER and REMIND. In my opinion, such a summary of viable alternatives is key to moving this in the right direction.

Ironically, after my previous posting in comment #74 I did find a use-case for REMIND which I find useful and which is not yet covered by the suggested alternatives. I'm wondering if the community could suggest an alternative for this:

During our M6 milestone&test week, a bug was filed with pretty severe impact. I was able to fix the impact with a workaround (aka quick hack), and well knowing that I'd need to look at this issue again later I decided to set it RESOLVED/REMIND. Note that for the bug reporter, the issue was indeed resolved; but I needed a reminder for myself that I'll need to look into this again.

Considering the issue with our M6 done and a little distance, I think what I'll want to do in this situation the next time is this: set the bug RESOLVED/FIXED, but also create a clone of it which is "Enhancement"/OPEN/Assigned to me. The new bug would track the required overhaul of the workaround while the old one would remain fixed (since I'd never really want to REOPEN it anyways).

I like all the other proposals except the very first one (since new bugs typically arrive with default milestone --- it's not a good idea to remove it).

(In reply to comment #76)
Alex - I don't see things that negative. We're having a great, open discussion and IMHO the final word has not been spoken yet.

I'm wondering if with Denis' compilation of suggested alternatives, those who voted -1 could perhaps be pursuaded to reconsider their voting?

Otherwise, "deprecation" is a good concept to keep existing searches intact but discourage using the concept in the future. Unfortunately, bugzilla doesn't warn about discouraged usage like Java - I'd be in favor of a warning dialog like Steve has suggested. Or would it be possible to keep REMIND and LATER in the masks for search only, but remove them in the mask for changing bugs?

Comment 80 Ed Merks 2007-04-10 09:21:12 EDT

I think we should all remain respectful of reasonable differences of opinion.  

Reading all the postings, I'm not sure anyone was expressing annoyance with those of us who disagreed with the seemingly urgent need to eliminate REMIND and LATER.  People might not like these states for the valid reasons given, but that's not the same as being annoyed with other people who differ in their opinion.  Certainly my use of these states is very limited and no one has ever accused EMF of hiding bugs or subverting the processes to manipulate perceptions, so I don't see this issue as something of great import (though I fully understand that might not be the case for other projects that are using this extensively to reduce the flood of bugs in their lists).

Similarly, I think it's grossly unfair to draw the conclusion that public opinion makes no difference at all on what happens at Eclipse.  Overstating a point really doesn't help make it stronger.  Quite the opposite, it makes it seem biased and perhaps even ill considered.  My opinion counts as public opinion just as much as anyone else's opinion.  In fact, I invest a great deal of personal time in helping the community so my opinion should not be summarily dismissed as annoying and counter to the public good. None of us can claim to represent the community better than any other...

Given EMF's limited use of these states, I'd certainly be willing to go with whatever the group consensus decides is in the overall best interest of the community as a whole.  My -1 vote is intended primarily to add balance.  I really don't see this as a major issue for my projects, one way or the other.  

It seems to me that this issue is just as easily resolved simply by reaching agreement with the projects who use these states extensively to change their process in favor of alternatives that are already available or new ones that will work better.  In any case, let's remain constructive and not bait each other with extreme statements...

Comment 81 Martin Oberhuber 2007-04-10 09:36:35 EDT

Thanks Ed.

Looking through the comments again, I really see two distinct issues here:

a) The question whether REMIND and LATER should be used when working on bugs
   in the future - If I did not oversee anybody it looked like the suggested
   alternatives cover all current usage in a good way

b) The question whether the database can be purged of existing REMIND/LATER
   bugs by changing them - looks like we still have a no-go on that one?

Which leaves the question whether a split solution of allowing queries for REMIND/LATER but not setting them when working on bugs is possible and viable?

Comment 82 Ed Merks 2007-04-10 09:55:16 EDT

I'll change my vote to "?" and agree to abide by whatever the group consensus decides will work best.

As I said already, I can use WONTFIX for enhancement requests that I would not consider addressing without a functionally complete contribution, and I can use WORKSFORME for bugs that don't contain enough detail to reproduce the problem.  So if there are even better alternatives, I'm happy.  If there aren't, I won't be upset.

Comment 83 Marius Slavescu 2007-04-10 12:04:44 EDT

Created attachment 63382 [details]
List of bugs with LATER and REMIND resolutions

Although I don't like LATER and REMIND resolutions, when I look at the list of bugs with these resolutions, I think would be good to hear the opinions of the heavy users of these resolutions.

Please see the attached ZIP-ed Excel file for more details.

One interesting case which was probably not covered is REMIND/LATER and CLOSED, what is the meaning of this state (you'll find this case in the spreadsheet)?

In my view both LATER and REMIND could be probably replaced with "help needed" and/or "remind" keywords and keep the resolution "---" or use target "future"/"---", also use the priority and voting to manage the interest level.

When we use WONTFIX, I believe we really mean that we won't look at bug anymore.

Comment 84 Aaron Digulla 2007-04-10 15:39:17 EDT

(In reply to comment #80)
>  Certainly my use of these states is very limited and no one has ever
> accused EMF of hiding bugs or subverting the processes to manipulate
> perceptions,...

I did. Several times. You ignored me but that doesn't change the fact that I felt your treatment of my bugs (= what I cared about) on the verge of abuse.

And I think this is something everyone here should be aware: Reporters of bugs can't see how stressed the Eclipse teams are, what their priorities are, what they can't do. I try to do something, I loose time and work. A bug must hurt to some extend before someone takes the time and effort to file it. So I'm in a bad mood when I write a bug report. When I report bugs, "LATER" screams "WE DON'T CARE!" and "GO AWAY!". It just rubs me the wrong way and the emotional content of some comments shows me that I'm not the only one who feels that way.

For these reasons, I've stopped to report bugs against EMF because the responses to my bugs clearly showed that I was neither welcome nor would I ever get anywhere.

And *that* shouldn't happen.

Comment 85 Ed Merks 2007-04-10 16:15:07 EDT

Aaron,

For the 9 bugs you've opened against EMF 

https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=EMF&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&emailreporter1=1&emailtype1=substring&email1=digulla%40hepe.com&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

only one is marked with REMIND and it has the suggestion that you pursue getting JFace to provide a better check box cell editor and then reopen the bugzilla for us to use it:

  https://bugs.eclipse.org/bugs/show_bug.cgi?id=75624

Of the other bugs, one is still open (the data binding support), two are marked WORKSFORME (because they do), two are marked as WONTFIX (because I won't), and three have been FIXED, because they are working well now.  We've even logged one of those fixed bugs as a contribution; I didn't think that was sending the message  "Go away, we don't care about your ideas."

So I'm a quite taken aback that you would characterize the handling of these bugs as verging on abusive.  :-(  I doubt your axe would have been dulled by having returned that one bug as WONTFIX instead.

Comment 86 Aaron Digulla 2007-04-10 16:40:02 EDT

(In reply to comment #85)

> So I'm a quite taken aback that you would characterize the handling of these
> bugs as verging on abusive.  :-(  I doubt your axe would have been dulled by
> having returned that one bug as WONTFIX instead.

Ed, this is just an example, okay? The whole EMF episode is something I'd rather forget. I tried to be professional about it but your comment "No one ever had any problems with the way I work" just blew me away.

The two WORKSFORME certainly don't work for me, same for the two WONTFIX. These four bugs essentially make EMF useless for me. Thank you for the three fixed ones but that still means that you are ignoring six out of nine bugs I filed. Hence my emotional reaction.

Which is what this issue here is all about: Of course, Eclipse is an OSS project and I get what I pay for. But there is also a personal side to all this. Emotions are hurt and this issue here has become a major pain. I've had to swallow several "Stop reopening bugs" by several teams (aka "each team does its own thing"), a lot of bugs that I care for (but didn't find the time to work on, so no blames here) just hang out there in LATER limbo (aka "we ignore you").

Therefore my advice: Setting a bug to LATER or WONTFIX or WORKSFORME also sends a message. Please always take into account that the reporter probably cares about the problem and they will look the "resolution" subjectively.

Comment 87 Ed Merks 2007-04-10 17:05:07 EDT

Aaron,

Yes, it's an example but to me it's an example of a reasonable use of remind.

As for what as for what I said, what I actually said was "no one has ever accused EMF of hiding bugs or subverting the processes to manipulate perceptions" so to turn that into "No one ever had any problems with the way I work" seems an intentional distortion of my words. Certainly with some frequency people are not happy with the way things are resolved; of course that's only when it doesn't result in the instant changes they'd like to see.  But that has nothing to do with REMIND/LATER verses WORKSFORME/WONTFIX.

Take https://bugs.eclipse.org/bugs/show_bug.cgi?id=75991 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=75993 as examples of things that do indeed work but that you continue to assert don't work.  What can I do except explain how it works? 

In any case, for someone who wants to put issues behind them, you certainly seem more inclined to sharpen your axe instead.  Your style of interaction is really not the most pleasant so the old expression "You'll catch more flies with honey than with vinegar comes to mind".  (I really shouldn't give lessons in diplomacy though since my skills in this area are often sadly lacking!  This likely being a case in point.)

Comment 88 Denis Roy 2007-04-10 17:36:01 EDT

I can't help but notice we've going offtopic. A community is not just you or just me, it's us together, so we need to agree that sometimes we'll disagree - and that's okay.

Back on topic, I think Ed's assessment of this issue is fair: although most of our committers agree that LATER/REMIND are not good, the issue here is not critical in any way. I'll do what I can to push the idea that LATER/REMIND are obsolete and shouldn't be used (I like Steve's suggestion of a popup), but I think that to pursue the issue more aggressively is simply not the best way to use our committers' time.

Over time, if the notion that REMIND/LATER being obsolete becomes well understood, we can investigate mass bug changes. David's comments of letting the issue evolve is, IMO, a great course of action.

Here are the actions I intend take to get this bug FIXED:

1. (Denis): Gather feedback from committers and the community (done)
2. (Denis): According to feedback, propose alternatives (done)
3. (Denis): promote to committers that LATER/REMIND is BAD (I'll start this thursday with an e-mail to committers)
4. (Denis): Casually monitor the usage of LATER/REMIND, return to 3. if usage doesn't change
5. (Denis): In several months, once usage patterns have changed and that LATER/REMIND are no longer used for new bugs, propose mass change to old bugs, then delete the offenders.

Assigning the above 5 actions to myself, and lowering priority as I won't spend every waking moment of my time on this.

Comment 89 Johan Walles 2007-04-11 01:40:39 EDT

(In reply to comment #87)
> Yes, it's an example but to me it's an example of a reasonable use of remind.

IMO no use of REMIND is reasonable.  The word REMIND doesn't in itself say anything about who is to be reminded about what.  Until I found this bug report I had *no idea* that REMIND meant "the reporter is expected to add more info".  The documentation for REMIND (at https://bugs.eclipse.org/bugs/page.cgi?id=fields.html#status) says that "The REMIND resolution is deprecated and should not be used.".  That doesn't tell me either who is supposed to be reminded about what.

If REMIND really means "NEEDINFO", how about simply renaming REMIND (which is meaningless) to "NEEDINFO" which would tell at least me what it's all about?

Comment 90 Gunnar Wagenknecht 2007-04-11 02:24:28 EDT

(In reply to comment #88)
> 3. (Denis): promote to committers that LATER/REMIND is BAD (I'll start this
> thursday with an e-mail to committers)

Part of the promotion could be renaming them by appending " (DEPRECATED STATE)" if Bugzilla would allow this. 

BTW, I don't see LATER/REMIND going completely until https://bugzilla.mozilla.org/show_bug.cgi?id=101179 is resolved.

Comment 91 Denis Roy 2007-04-11 15:01:45 EDT

(In reply to comment #78)
> How about this: LATER and REMIND are deprecated.  What about a warning dialog
> every time they are used?
> 

I added a bit of javascript to the page to show a warning when REMIND or LATER are selected. Hopefully this will work on all browsers. Thanks for the idea - this should really help drive the idea home.

Comment 92 Denis Roy 2007-04-11 15:05:22 EDT

Created attachment 63534 [details]
Screenshot of warnings when LATER or REMIND are chosen

The circled text appears on the screen after the popup warning is displayed, and stays there unless another resolution is chosen.

Comment 93 Gunnar Wagenknecht 2007-04-11 15:11:17 EDT

(In reply to comment #92)
> The circled text appears on the screen after the popup warning is displayed,
> and stays there unless another resolution is chosen.

Mhm, I'm not sure about the pop-up dialog. What happens if you select this by accident? The pop-up hurts usability.

If we all agree on not using them for new bugs. What about disabling the submit button if these resolution are selected? Would that be too drastic?

Comment 94 Marius Slavescu 2007-04-11 15:42:32 EDT

(In reply to comment #92)
> Created an attachment (id=63534) [details]
> Screenshot of warnings when LATER or REMIND are chosen
> 
> The circled text appears on the screen after the popup warning is displayed,
> and stays there unless another resolution is chosen.
> 

Please could you change the combo options to show what resolutions are deprecated, like here:

      <option value="FIXED">FIXED</option>
      <option value="INVALID">INVALID</option>
      <option value="WONTFIX">WONTFIX</option>
      <option value="LATER">LATER (deprecated)</option>
      <option value="REMIND">REMIND (deprecated)</option>
      <option value="WORKSFORME">WORKSFORME</option>

and later when the decision to disable them is made you just remove them from the list.

Personally I don't see a need for the pop-up warning during the deprecated stage.

Comment 95 Denis Roy 2007-04-11 15:58:32 EDT

> Please could you change the combo options to show what resolutions are
> deprecated, like here:

The drop-down is populated from the database, and I wasn't sure if it used an arbitrary description or the actual database key itself, but it does use an arbitrary description (I'm surprised). After tracking it down (bugzilla has stuff all over the place) I changed the description to LATER and REMIND to LATER (deprecated) and REMIND (deprecated).

I also removed the pop-up, but left the little on-screen message with the link, as it points to alternatives.

Comment 96 Michael Valenta 2007-04-11 16:17:47 EDT

If you can change the description, why not just change the description of REMIND to NEEDSINFO as suggested in comment 89? Personally, I don't care about whether LATER stays or goes but I need some way of marking a bug that requires more info so it doesn't show up in my list of bugs that I need to triage.

Comment 97 Denis Roy 2007-04-11 16:20:06 EDT

(In reply to comment #96)
> If you can change the description, why not just change the description of
> REMIND to NEEDSINFO as suggested in comment 89? Personally, I don't care about
> whether LATER stays or goes but I need some way of marking a bug that requires
> more info so it doesn't show up in my list of bugs that I need to triage.
> 

Because the bug would still be in a resolved state.  I created a keyword called needsinfo for this purpose.

Comment 98 Steve Northover 2007-04-11 16:58:02 EDT

Whatever you do, do not rename either LATER or REMIND.  That will blow the minds of everyone on this bug report.  

BTW: I was half kidding about the dialog (but it sure would annoy the heck out of people who are still using these @#$%$@# deprecated things and it almost happened!).

Comment 99 Alex Blewitt 2007-04-11 17:03:08 EDT

(In reply to comment #96)
> If you can change the description, why not just change the description of
> REMIND to NEEDSINFO as suggested in comment 89? Personally, I don't care about
> whether LATER stays or goes but I need some way of marking a bug that requires
> more info so it doesn't show up in my list of bugs that I need to triage.

Can you amend your query so that e.g. it ignores bugs with a keyword with a
'later' or with priority 5?

The problem with whatever it's called is that it's a *resolution* state, not a
sub-state of any bug. If it's not resolved, it shouldn't have anything there.
It's not a flag for generic filtering of bugs.

The other approach is for new bugs coming in to be UNCONFIRMED, and the
list-of-triage is the set of UNCONFIRMED bugs (and they get promoted to NEW
once they've been triaged).

Comment 100 Nick Boldt 2007-04-11 20:42:24 EDT

(In reply to comment #95)
> > Please could you change the combo options to show what resolutions are
> > deprecated, like here:
> The drop-down is populated from the database

If you can hack the page w/ javascript, couldn't you also hack in a change to do something like:

<script>
onload = doOnload;

function doOnload()
{
  field = document.forms[formName].elements[fieldName];
  field.options[3].text += "(Deprecated)";
  field.options[4].text += "(Deprecated)";
}
</script>

Comment 101 Denis Roy 2007-04-11 20:52:47 EDT

(In reply to comment #100)
Nick, you should read *all* of comment 95  :)  I found where the description was stored (in a template file) and updated it.

Comment 102 Nick Boldt 2007-04-11 23:26:56 EDT

(In reply to comment #101)
Damn, sorry. 

Comment 103 Denis Roy 2007-04-16 17:11:57 EDT

This query will allow us to track how many bugs were set to REMIND or LATER since the resolutions were marked as deprecated on Apr. 11.

https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&resolution=LATER&resolution=REMIND&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=2007-04-12&chfieldto=Now&chfield=resolution&chfieldvalue=LATER&chfieldvalue=REMIND

I'll use the query to casually monitor REMIND and LATER usage trends.

FWIW, using Edit Search on the above query will break the query, as I added values in the URL directly to bypass a GUI limitation.

Comment 104 Denis Roy 2007-06-20 11:04:04 EDT

Just as an update, bug 193514 and bug 193523 are definitely interesting.

Comment 105 Denis Roy 2008-10-14 15:16:56 EDT

Just doing some bug triage when I stumbled upon this nugget.

In the year-and-almost-half since I've last posted here, I think we (collectively) have successfully schooled ourselves about the evil that is LATER/REMIND. Only 77 bugs have been filed as such since April 2007, despite almost 100,000 new bugs being filed.  Most teams have adopted one of the many solutions within this bug to avoid using those deprecated resolutions.  In my book, that is Mission Accomplished.

At this point, I don't think anyone gains anything by forcibly eliminating LATER/REMIND altogether, and I don't think the resolutions, being visible with their "deprecated" label, hurt or distract.  In other words, I don't see why I'd embark on a painful campaign to convince/push teams to change their remaining LATER/REMIND bugs to anything else. 

Closing as FIXED.  Thanks to everyone who has helped bring on this change.