Duplicates on meta sites - sum the votes

Question

Duplicates are there mostly to tell us that a question was already asked and, in some cases, it also has an answer and to link to this question.

While this is great for main sites, on meta it's a bit trickier.

We know that on meta we:

• discuss various topics
• propose various features
• ask for support
• and report bugs.

We also know that on meta, voting is not working the same as on the main sites. Here, it represents that others agree and supports that (or not, in case of downvotes).

So, when we meet a duplicate on meta, it actually means that somebody else who didn't find the original post agrees and supports the same question and that whoever upvoted / downvoted the duplicated question, also agrees/disagrees with original post.

However, if I'm not totally wrong here, those votes are lost - we only know there's a duplicate when we visit the duplicate question. The original question doesn't show that in any way in the UI.

So...:

1. We should show, in the original question, that the same thing was requested in other words;
2. We should sum the total of upvotes/downvotes, in the original question, and display them in the UI broken down per each duplicated question

But why not sum the votes directly you ask? Why show them broken down per duplicated question?

Well... having full transparency as to how the voting occurred might be relevant when making the final decision (e.g. status-something), and might help others to agree/disagree by seeing other points of view that are considered duplicates, and how others perceived them.

Obviously the linkage and summing the total votes needs to be validated, so that if the same person upvotes all duplicates / upvotes one and downvotes the other, the total votes is still consistent and reliable.

To that end, I would simply show latest vote from a distinct person.

Answer 1

In addition to the fact that people already follow the link and vote on the other question, very few duplicates are exact duplicates. I've seen many questions where the request was something I wouldn't support, but a different solution to the underlying problem was fine. Another post that addresses the same underlying problem might do so in a different, upvote-worthy, way, yet be grouped together with the first. Users vote on posts; the system should never vote on our behalf on other posts because it thinks we would want to.

Making it easier for any member of a duplicate cluster to show the links and votes for all the other members, so that people can review related posts and evaluate the bigger picture, could be worthwhile. Provide information, not vote transference, in other words.

Answer 2

If a new post gets closed as a duplicate, this already has an effect on the original post. The original post is linked in the new duplicate, and people can follow that link and upvote the old post. It's pretty obvious when an old post of mine on meta gets used as a duplicate target, that almost always results in a bunch of additional upvotes for me. So I doubt that this change would have a very large effect.

Post scores on meta are also not that important. They're useful for a rough impression on whether the community likes or dislikes a specific idea, but the exact score doesn't really matter much. It makes almost no difference whether a post has a score of 50 or 100. It's not worth it to add any complexity to this.

Answer 3

The use case at hand is already covered by existing site features:

---

• If the duplicateness is discovered shortly after the question is posted, the solution is to close as duplicate.

  • Then the prospective voters will see the duplicate banner and are expected to go vote on the master question (or both).

• If the fact is discovered after both posts have coexisted for quite some time and accumulated a hefty sum of votes, the ideal solution is merging.

  • The catch here is such posts are often not exact duplicates but rather "closely related", or have different focuses.
    • For the purpose of the site's M.O., that means the answers for one will not fit if moved to the other verbatim.
    • Of course, they can be edited to fit, but drastically changing a post's meaning would be appropriating its votes (because people voted on a different set of sayings than what you make the post into, so you can't be sure they would vote the same on yours).
    • So, in these cases, the "least evil" solution seems to be just prominently link them to one another.

Answer 4

I support this.

Take, for example, this feature request. By itself, it looks like a very old, outdated request from 2012 that may have since been implemented. As such, many people, including Stack Exchange employees, may overlook it. However, if you check the Linked section at the right, a section which our eyes don't naturally gravitate to, you'll see a duplicate question that was posted yesterday. The fact that that duplicate was posted means that the request from 2012 is still valid today.

In this case, the author of the duplicate didn't initially know of the initial request. They may not have searched for it, or they may have searched, but not found it because they used different wording. (On main Q&A sites, this is intended, as duplicates with different wording are useful as search fodder to help users find the answer with both wordings.) Also, consider this bug report from 2013, which is still an ongoing bug as evidenced by this duplicate. This case is even worse because, as there are five linked questions, it isn't immediately clear merely from the Linked section that the bug is still present.

The general attitude of the community, as evidenced by these two cases, is to always close the newer report or request as a duplicate of the older one. (I disagree with this, and think that the older one should be closed as a duplicate if the newer one has more details, and it also has the advantage that as the newer one is the canonical question, it's more clear that the requests are still valid.)

What's supposed to happen, in theory, is that if the newer report gets closed as a duplicate of a much older one, the author or another user is supposed to edit the older report at a minimum to explain that it's still ongoing, and possibly with the further details supplied in the duplicate. However, in practice, this doesn't happen, especially as many users are loath to edit someone else's question drastically, because the guidelines on main sites are to avoid editing drastically as it could change the meaning of the question, and to avoid editing comments into posts. Also, it's possible that reviewers may be applying this policy to reviews, and wrongly rejecting such edits. Another possibility is that users do find the old request, and for various reasons (not only the editing policy, but also by rules on forums to avoid bumping old threads) choose to post a new one.

Also, what happens in practice if such a duplicate gets posted and gets closed is that the feature or bug fix doesn't get implemented. As the votes are now fragmented across two questions, it doesn't get enough votes to be noticed by the team.

If the community is insistent on keeping the policy of always closing the newer question, even if it has more details and by its very existence indicates that the old report is still valid, and users aren't getting that the editing policy is different here on meta, we need this feature to help ensure that such requests are getting noticed.