Closed (duplicate)
Project:
Drupal.org customizations
Component:
Miscellaneous
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
29 Oct 2007 at 11:00 UTC
Updated:
21 Aug 2014 at 21:00 UTC
Jump to comment: Most recent
Comments
Comment #1
gregglesYou said "treated the same as closed" but I think you mean "treated the same as fixed" right?
That seems reasonable to me. What about "by design" same thing, right?
Comment #2
catchoops! Yes I meant "treated the same as fixed". "By design" (and postponed if it's the same deal although there's less of those) I'd also include in this.
Comment #3
gregglesI don't think postponed should be included here. I only think that the states that have no possibility of resurrection should be moved to "closed". In theory we'll get back to the "postponed" items eventually so automatically moving them to "closed" only to have to move them back to "active" seems like an unnecessary status change.
Comment #4
catchGood point. To be honest I don't see a need for postponed at all. Given that there's generally a version tag at least one release ahead most of the time instead of HEAD, I think this could be considered for removal altogether - just bump a version up to postpone it, patch status still stands most of the time.
Comment #5
dwwA) I occassionally (perhaps because I'm sick and like to remind myself of pain) like to query for just how many "duplicate" issues I've had to participate in. If they automatically moved to "closed", there'd be no way to distinguish them, do historical analysis of just how many duplicates we have, see if it's a pretty even % across projects of if there are some projects that are more prone to duplicates than others, etc. I see this as valuable information that can be used to make improvements which we'd be losing.
B) "Postponed" is incredibly useful, no way I'd undo that. A few examples: not everything that's postponed has a specific version when it's going to be active again -- I regularly use postponed to indicate that issue #12345 is blocked on issue #23456. I have no idea when #23456 will be solved -- depends on who actually does some work on it. Moreover, it's a special case we use for the core issue queue to have a "7.x-dev" version string available in the issue queue long before there's a branch with any 7.x-specific code. So, even if we added a "waiting for..." status to deal with non-version-specific postpone uses, we still couldn't even do version-specific postpone without a big hassle for contrib maintainers and someone writing a bunch of code to make it easier to setup these "future versions" for the issue queues. This part of the proposal is definitely "won't fix".
C) As soon as we roll out "IFAC" ("issue followups as comments") on d.o (see http://drupal.org/node/186829) the "My recent posts" page will show all issues you submitted *and* replied to, and it'll always show when they're updated, regardless of their state. That should seriously help the original problem mentioned here -- issues will never "disappear" from your tracker page, only the default query on the "my issues" page.
D) I wouldn't mind a way for users to set the default issue status for their "my issues" query somewhere in their profile. See http://drupal.org/node/56200 for more. In fact, this issue is duplicate with that. See also http://drupal.org/node/138056 for another angle on solving this problem.
Cheers,
-Derek