123

I love that posts closed as Off Topic and migrated to another site now say [migrated].

Can we do this for a [duplicate] as well? The distinction between a question closed as duplicate and one that is closed as not a real question, too localized, or otherwise "bad" is at least as big or maybe even bigger than those that are migrated.

Unless the original is also closed, then the duplicate is just as valid but already answered — and this would prevent users browsing the question lists from assuming anything else about the question (such as Weird, maybe X is off topic here?)

3
  • 6
    also, [merged] wouldn't hurt May 17, 2011 at 7:25
  • 1
    How about making the title say [sic]? May 17, 2011 at 7:39
  • 1
    yes please do this pretty please
    – Kip
    May 18, 2011 at 19:54

3 Answers 3

41

This is a thing that we do now:

enter image description here

14
  • 3
    Go on, tell us how you do it.
    – ChrisF Mod
    Jan 22, 2013 at 21:27
  • 2
    @ChrisF I have no idea. Magic and some C#?
    – Adam Lear StaffMod
    Jan 22, 2013 at 21:28
  • You can do better than that :)
    – ChrisF Mod
    Jan 22, 2013 at 21:29
  • Magic, C# and SQL I bet
    – Ben Brocka
    Jan 22, 2013 at 21:30
  • 6
    @BenBrocka SQL is magic.
    – Adam Lear StaffMod
    Jan 22, 2013 at 21:30
  • 3
    My little Database SQL is Magic
    – Ben Brocka
    Jan 22, 2013 at 21:32
  • 7
    The query is already being done to determine what something was closed as, so the result is memoized and reused for the title suffix. MEMOIZATION, F*&$ YEAH! Jan 22, 2013 at 21:33
  • 4
    Also, brace yourselves for more changes around duplicates. Jan 22, 2013 at 21:34
  • 2
    And if some database changes were involved, then maybe adding a search option duplicate:yes is doable too? (Next to the existing closed: and migrated. I have no idea if that is useful though...)
    – Arjan
    Jan 22, 2013 at 21:34
  • Shouldn't it say "duplicated" with a "d" to match "closed" and "migrated"?
    – animuson StaffMod
    Jan 22, 2013 at 21:35
  • 7
    @animuson No: the closed question is the duplicate, it's the other question that's duplicated. Jan 22, 2013 at 21:37
  • 2
    @JarrodDixon Like this? Jan 22, 2013 at 21:40
  • 2
    This is great, because it's more conciliatory than "closed", but has the same effect.
    – AndrewC
    Jan 22, 2013 at 21:41
  • 2
    @Arjan a search operator isn't in the plans, yet, but it might be. One would have to plead with Nick Craver to add it to the elastic search models :) Jan 22, 2013 at 21:43
2

If the only problem is extra DB lookups, how about literally modifying question title to add "[duplicate]" string instead? There's hardly any chance they'll be reopened back and need any editing, so this won't get in anyone's way. Yes, "[duplicate] [closed]" looks heavier, but I'd be willing to look over it to see duplicates at a glance. Or it can even be cut down with site JS or userscript.

And even in a miniscule amount of cases when such a question is somehow reopened it is still small feat to remove it manually or system can even clean-up this automatically too.

3
  • The code still needs to make an extra query, to know the closing reason. The migration date is saved in the "Posts" table, but the closing reason (e.g. off-topic, not constructive, not a real question) is saved in a different table.
    – apaderno
    Sep 25, 2012 at 12:26
  • 2
    @kiamlaluno, it seems you didn't understood: on closing, "title" column should be modified by appending literal " [duplicate]" suffix to it. Displaying title with those words in it, naturally, doesn't require any more lookups that any other title. Sep 25, 2012 at 12:45
  • 1
    That's a non-robust and non-semantic approach that would not pass code review in my team. Jan 24, 2013 at 7:00
1

No -- not without incurring one SQL query per every displayed element on the page.

[migrated] was possible because we store a MigrationDate on the posts table. There is only CloseDate; to get the reason for the close we would have to dig into the post history table which is massive.

I don't feel this feature is so important it is worth that amount of performance and engineering work at this time.

5
  • 4
    That's very reasonable. We need more performance. But would it be reasonable to include close reasons in the Posts table or is that change too costly to do right now? May 26, 2011 at 23:12
  • 22
    I get that it's expensive. But when you look at a lower-volume site with a lot of closing (eg programmers.se) the [closed] markers are telling what's welcome here and what's not. When things are closed as dupes they look unwelcome, which they're not. I think the "first impression" is better when dupes are marked as such. Jul 14, 2011 at 14:53
  • 1
    While the "programmer time" argument might be valid (although I'd personally consider it worth it, and would volunteer to help if I could), the performance impact could be easily eliminated, at the cost of a small amount of database denormalization, by adding a CloseReasonId column to the posts table. It could even be populated gradually by a background job. Mar 13, 2012 at 18:28
  • Ps. In hindsight, it would probably have been better to use a CloseHistoryId column, pointing to the appropriate row in the PostHistory table, instead of CloseDate. That would've required an extra (left) join to get the closing date, but would've made all the other information in the history row just as easily accessible. I suppose it still wouldn't be too late to switch... Mar 13, 2012 at 18:33
  • 3
    How easy would it be to check the post body to see if it starts with "Possible Duplicate"?
    – ChrisF Mod
    May 5, 2012 at 12:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .