Review queue
From Freebase
The review queue is where all topics which are flagged for delete or merge end up to be reviewed by other members of the community. The review queue helps prevent accidental or malicious deletion of topics, but it relies on members of the community to help out and vote on topics.
Contents |
When to delete a topic
- It is not factual, is a hoax, spam or malicious. These should be deleted as they don't fall within Freebase's Terms of Service.
- The topic is a list. Freebase uses views to automatically display list of topics, so doesn't need a manually created list of items. Most lists in Freebase are legacy items imported from Wikipedia.
- The topic is a topic about a topic. Examples include "Economy of Pakistan" or "Politics of Bahrain". The only applicable type might be "Field of Study" or "Literature Subject", but the data is more useful in properties on the actual topic itself. Most of these are legacy topics from a Wikipedia import. We'd rather clean up Freebase and delete the topic - the data can be transferred into properties at a later date.
Topics which were proposed for deletion because they are duplicates should not be deleted. Vote No or Disagree for these topics and instead flag them to be merged with the other duplicate(s).
When flagging a topic for deletion, please do not remove any of the data on the topic: doing this makes it very hard for other people to determine if deletion is the correct action or not.
Delete or merge?
In almost every case, duplicate topics should be merged, rather than one of the duplicates being deleted, even if the topic appears to be blank -- there may be links in the graph which do not show up via the client, or Freebase users may be referring to the topic from outside the graph itself.
One exception is Wikipedia disambiguation pages which should not be merged, even if they have mistakenly picked up data which corresponds to a concrete topic. This is because the topic contains a reference to the Wikipedia page, and by merging the pages we would assert that the two Wikipedia pages are about the same thing, which isn't the case. The correct action in this case is to move the data to the correct topic(s), and then delete the disambiguation page; if there's too much data to easily move by hand, flag the page for "split" and post a comment explaining the issue - staff and experts have access to a number of tools which can help here.
Another type of Wikipedia page that we'd prefer have deleted over merging (a much rarer case) are duplicate topic pages that are merely in actuality a redirect page. Redirect pages are when someone has created a page on Wikipedia on a currently existing topic and then later on get deleted and replaced with a redirect to the main topic page. Freebase may have imported that duplicate page if the import process was done while the page had not yet been replaced with the redirect. For the duplicate topic on Freebase, if the only information attached is a Wikipedia key, mark the page for deletion. If there are some incoming links or data attached, we prefer to have it split off and merged to the main/root wikipedia-sourced topic page. It won't harm anything to have merged the duplicated redirect Wikipedia topic, but it does add an unnecessary key to a topic that already may have many keys attached.
How many votes?
The review queue needs 3 unanimous votes before it will delete or merge a topic. If the voting is not unanimous, an expert needs to make a tie-breaker vote.
The RQ needs three unanimous votes (unlike most Data games which take the first answer) because of how hard it is to revert a deletion or merge.
In addition to non-unanimous votes, there are a number of other conditions which will delay an automatic merge and require an extra review. Some of these include:
- "losing guid has more than 200 incoming and outgoing links",
- "losing guid has a key in a system namespace (/lang); losing guid has a system type (/type/lang)",
- "losing guid was created by a metaweb bot (<bot user name>)",
Complex merges: left vs right
When two topics are voted for merge, the system can't figure out which one should take precedence. For instance, imagine two topics "John Smith" and "Jonathan Q. Smith" which are actually the same topic. Which name should the resulting merged topic have? The left/right vote chooses which topic's data should take precedence in the case of clashes like this, so you should pick the topic which contains the "better" data, including the name of the topic, for any clashes like this. Unfortunately, the voting has no effect on which article blurb is displayed in the merge winner.
If both choices are equally good (for example if they contain no inconsistent data), try to pick the topic which is better filled out. This is largely an artifact of the review process: if the voting is not unanimous, the task will get kicked to an admin for additional review, so if we all manage to vote the same way in cases like this then we reduce the admin workload.
Vandalism
Like wikipedia anyone can flag a topic. Flags are stored in the Freebase graph and can be added through freebase.com or through MQL. However, it is considered a breach of the trust and good will of the community to delete a flag before voting has completed. The only exception to this rule is if you are original flagger and no votes have been recorded for the task yet.
Timeline
The amount of time it takes for a task to work its way through the queue depends on the backlog of flagged tasks and the number of people voting on the queue. It can take anywhere from less than a day to several days for a task to be processed.
Once a tasks receives enough votes it is pulled from the queue for processing. If voting is unanimous then the action associated with the task is performed, otherwise it is sent to the admin queue for additional review.
Admin
Staff and Freebase Experts are admins of the review queue. The job of admins is to provide "tie-breaker" votes when the community has given conflicting votes. You can find the admin interface at http://www.freebase.com/tools/flags/review?admin=1
