'fixed' issues should not be automatically set to 'closed' - perhaps 'postponed' ones as well

@ Gábor: That is exactly the issue... 'fixed' issues should NOT be auto-set to 'closed'. We should use 'closed' only in cases where -for example- the maintainer asks for more info and the reporter of the issue never responds back.

@ Dave: I know you see the status on hover. You actually don't need to, since the links are color-coded. Perhaps I didn't make myself clear (or my post is too long and boring to be read carefully). Please, consider this scenario (it happened to me a lot of times):

- I have some issue I need to report. So I search for any similar issues first, before (re-)reporting and causing possible duplicates.
- While reading a history of an issue, I might see a post that links to another issue and states that this one needs to be addressed first.
- The link states (color + hover tooltip) that this issue is closed. So, the current issue I am viewing, that depends on the second, cannot move on.
- I visit the link of the second issue (that my current issue depends on) and see that it actually was fixed at some point in time, but after inactivity it was changed from 'fixed' to 'closed'.
- Back to the first issue I was checking out, I realize that the maintainers were never informed that the required issue was fixed so they can do something about the current one. (here's where my suggestion to have a 'depends on...' state comes from)
- Time passed and now when people see the history of the current issue, they think that it reached a dead-end, because the last update they have is that it depends on another issue that is marked as 'closed' and not 'fixed' as it should. (here is where my suggestion to keep 'fixed' issues from auto-changing to 'closed' comes from).

As for people clicking through a series of depended issues in order to see where the main issue that they were initially looking at stands, I believe it should be the last thing that people should have to do, when we can have each issue auto-updated upon solution of depended issues and maintainers informed through email about it. The way it is now, a maintainer needs to go to the required issue and add a comment (usually 'subscribing...') in order to stay informed. Even then (if a long time passes before it gets solved), he might not even remember why he subscribed to the issue in the first place.

Does all this make any sense to you?

forgot to set it back to active...

I know what you mean and I must admit that I was expecting that someone would step up and make that exact point. Which is why I had an answer ready for it...

As it is now, the issue queue of each project excludes 'closed' issues by default. Actually is displays all 'Open' issues... as in 'all-that-are-NOT-closed'. We could have it exclude both 'closed' and 'fixed' and that my friend would prevent long lists. After all, a 'fixed' issue is not an 'Open' issue and shouldn't be included in the queue like it does now.

I hope I've made myself clear... I mean that there are two 'abstract' main categories of issues... opened and closed ones. In order to avoid misunderstanding the abstract category of closed issues with the ones that are actually marked as 'closed', I'll call them 'done-with' and 'not-ready-yet' respectively. So... now we have

- not-ready-yet issues:
- active
- needs work
- needs review
- fixed
- ... so on ...
- done-with:
- closed
- duplicate
- won't fix
- by design

What I propose is to move 'fixed' issues to the done-with list (that won't be displayed in the issue queue same as 'closed'). Also I propose to not have them auto-set to 'closed' status after inactivity.

So I kindly still insist in my request... a fixed issue is not a closed issue and shouldn't be treated like so.

... Now, for the postponed ones... there are two shorts of them. The simple 'postponed' ones and the 'postponed - maintainer needs more info' ones...

I understand that if someone does not reply with requested information, after some time 'postponed - maintainer needs more info' status should be changed to 'closed' (and thus moved to the done-with abstract category I mention above). That includes the most common use case where people think they have an issue and report it. People ask for more info on the issue in order to help them and set the issue to this state. If the issue reporters actually come back with a reply, the issue is either set back to 'active' if issue still remains, or set to 'fixed' or whatever depending on the progress. In the case where the reporters solve the issue by themselves and never come back to say they did (I know it's really rude, but it does happen) the system sets the issue to 'closed' due to inactivity. And all is good!

I am not so sure for the way simple 'postponed' issues should work though. My guess is that people set issues to this status when they mean to come back to them after some time. So they shouldn't be set to 'closed' (for these I am not sure if this actually does happen?). To support this thought of mine, consider the use case where module maintainers work on something big and say that they don't have the time for a minor feature request. If this is a legit request and they set it to won't fix, it will never be addressed. If they set it to 'postponed' someone else might come later on and work on it (or they might do so once time permits). If this is auto-set to 'closed', no one will know or remember it ever was there and it is as if the system decided that this feature request is not valid and set it to a 'won't fix' state.

PS: I tried to keep this short, but I've done it again... sorry :(

Dave, this is not a complaint. It is a legit request for improvement. I do understand the current way is how things run for years now, but if my proposal is indeed an improvement and makes sense, then please consider it. Excuse me, but 'It works as it is now' is just an excuse and not a reason to turn my proposal down.

I agree that there should be a way so 'fixed' issues should not be excluded till people coming to report issues take a good look at them being 'fixed' (to avoid duplicates). I also agree that the use case you present happens a lot too. How about letting 'fixed' issues visible as it is now and they will eventually reach the end of the queue? ...assuming that:

a) the default shorting method for the queue remains by time of last post
and b) that no one posts 'thank you!'s after a year or so ;)

Another solution to that would be to keep 'fixed' issues listed only for a certain period of time. I understand that this implementation would be complex compared to the first way (in which nothing needs to be changed), but still it is the right way to do it. I believe that the way it is now, instead of actually having it done the right way we use workarounds like the marking of 'fixed' issues as 'closed' simply to move them out of the queue list.

Now, you on your part, you most likely agree on the idea of the two 'abstract' main categories of issue states I mention above(?). You must also agree that common sense (of people that are new-comers to drupal.org) indicates the following:

1) an issue marked as 'fixed' is not considered an 'open' or 'active' one. But still, it is listed among the ones returned by the query when 'Open' is selected through the queue search filter drop-down. That is confusing! (having 'fixed' issues listed with the rest of the issues that are 'not-done-with' I mean).

2) an issue marked as 'closed' does not imply it has ever been fixed in the past (could be so, but not definitely). People will know for sure only once they dig through the history of this issue and this renders (to me) the whole color-coding feature useless (in this case).

Now, what I propose is based on (annoying) things that happen to me a lot while browsing issue queues and looking through some issues' histories. My english is in a level that I don't confuse meanings of words plus I do have experience with issue tracking systems (like the mozilla.org's bugzilla) and the way they work. So, when these annoying things happen, it's not just me (or so I like to think).

I will stop here in an effort to keep this as short as possible. Please let me know your thoughts on the points I've made above, and do keep in mind that I sincerely want only the best for the drupal community. Making things work better benefits us all.

thank you Derek, I will waste my next spare hours on that ;)

Also I wasn't sure about postponed issues (I did mention that in my posts) thanx for clearing that up for me too.