User:Lectrician1/Merge system proposal

This proposal stems for a discussion on the Wikidata Telegram group originally sparked by me, Lectrician1, suggesting we delete different from (P1889). This document summarizes that discussion and it's tangent about creating a new merge system to handle the expected increase of the merging of items that seem similar due to the then lack of different from (P1889). Please leave your feedback about this proposal on the Discussion page.

Why delete different from (P1889)?

Using and maintaining different from (P1889) is a manual task that can become very tedious for editors. This is especially true among similar large sets of items with the same label because all of the items in the set need must have different from (P1889) statements added to each of the items in the set.

Wikidata is a linked-data database. We have classes and different statements among items to define and differentiate them accordingly and powerfully. It should not be the responsibility of the editors to manually maintain a list of items that are different from another. Therefore, classes and statements should be appropriately added to an item and an item's description should further describe it so that it is completely understandable and differentiable between similar items by anyone. I believe that maintaining a comprehensible system like this without requiring the use of different from (P1889) is 100% possible for all items in Wikidata. It's going to take work and time, but the end result will not only ease the responsibilities of Wikidata editors, but improve the comprehensibility of Wikidata as a whole - something extremely important to consider when thinking about the complexities of Wikidata a new editor might face.

Merge system proposal

different from (P1889) currently serves a use: to let users know that similar items exist that they should be made aware of. Understandably, removing it will cause users to be unaware of those similar items. As a result, it can be reasonably estimated that the number of merge requests about similar items would increase. To counteract this increase as well as aim at decreasing the current number of mistaken similar-item merges, a new merge system should be implemented.

How it works

• Items can be merged by autoconfirmed users requesting an item to be merged by clicking the Merge button that will be enabled by default in the header without requiring the current gadget. Another user with at least 200 edits will be able to review the merge and either accept it, or decline and explain why it shouldn't be merged.
• When a merge request is filed, the merge will be "temporarily executed". This means that the item that will merged-into will create a duplicate of itself in the item draft namespace and the combination of the merged items will appear on that draft. This is to prevent users from changing or moving statements between items trying to "merge" the items before the merge is reviewed. It also places a responsibility on editors who want to edit an item after the request to review the merge.
• Merge requests about items that are on the Watchlist of a user who can review merges will appear highlighted.
• Warnings similar to the "the last edit to this page has not been patrolled yet" message will appear on the items requesting to be merged, notifying the editor that the merge must be reviewed before they can make changes.
• Users that do not have 200 edits who would like to request items to be merged can request them to be on the Admin Noticeboard as this is an unlikely occurrence.
• Merge requests will not show up in a user contribution's list to prevent the stalking of users and immediate cancellation of their requests.
• A user can file as many merge requests as they would like, as some users often execute many merges on items that have no statements to help clean them up. If a user is spamming unneeded merge requests, they should be blocked.
• A user can review as many merge requests as they would like. If a user is repeatedly unreasonably declining requests and not providing sufficient as for why, they should be warned or blocked.
• A merge request by a user cannot be filed between the same items that have been declined in a merge request made before by the same user. This is to prevent the user from repeatedly filing requests out if frustration of disagreement. The user can instead start a discussion with other users about whether the items should be merged and users in that discussion can request a merge for the original user if agreement that a merge is needed is met.
• The system must be able to handle "chained" merge requests and redirect items part of merge requests that were recently merged to their new item.

Possible concerns

• This will create a backlog of merge requests.
  • Merges make up a very small percentage of edits on Wikidata.
  • Most merges are for easily-recognizable duplicates created by batch jobs that can be reviewed in seconds
  • For items that are barely-seen and requesting to be