Corrections

A fact on Title Screen is wrong and you can show where the right value is written: suggest a correction. Corrections are issues on the public data repository, so each one is in the open with its evidence, and a GitHub account is needed to send one.

How to send one

Find the release the fact is wrong on (a game's page lists its releases: one per platform and market) and press Suggest a correction.
Pick the fact, give the right value, and link to the evidence.
The page opens the issue on GitHub, filled in. Say what kind of evidence it is and submit.

Five facts can be corrected this way: the release date in that market, the publisher, the developer, the genre and the players (the most who can play at once). A company is picked from the companies Title Screen already knows, or named as a new one; a genre from the genre table. Two different games joined as one, or one game split in two, go through the repository's other issue form, which a person reads.

What counts as evidence

From strongest to weakest:

Evidence	Weight
The game itself: cartridge, disc, box, manual or title screen (photo or scan)	3
The publisher's or developer's own record: site, press release, catalogue	2.5
A ratings board or registry: ESRB, PEGI, CERO, USK, ACB, a copyright office	2.5
A magazine or newspaper of the time (scan, with the page)	2
A reference book (give the page)	1.5
Another database or wiki	0.5

Another database counts for little because the sources Title Screen already reads are databases, and they often copy each other (see Methodology): a wiki that agrees with your memory is usually where the wrong value came from. A genre is a classification rather than a fact a document states, so any evidence for a genre counts at most 1.5.

What happens to it

When it is opened or edited, a bot checks every field against the live data: the release exists, the fact is one of the five, the value is of the right kind (a real date, a listed company, a genre in the table, a player count from 1 to 64) and differs from what is published, the evidence has a kind, a link and a sentence saying what it shows, and both boxes are ticked. A report that fails is closed with the reasons; fixing it by editing the issue reopens it.

Once a week (on Mondays) the bot reviews every open correction:

Reports proposing the same value for the same fact are rolled up into the oldest one, which then counts every reporter and every piece of evidence. Reports proposing different values for the same fact are marked as conflicting. Two dates where one is a more precise form of the other (1991 and 1991-06-23) do not conflict.
A correction a build has since applied is closed.
The rest are scored, to put the best supported in front of a person first. The score starts from the strongest evidence's weight, then:


A source Title Screen reads already states the proposed value	+2 from a dump list or the media, +1 from a web database, +0.5 for a date given for the game rather than this market
The published value is contested by the sources	+1
The published value rests on one source	+0.5
The published value was joined by title rather than by an identifier	+0.5
Nothing is published for the fact yet	+0.5
Three or more sources joined by identifier agree on the published value	-1.5
Each further person reporting the same value	+1, at most +2
Every reporter's GitHub account is under 30 days old	-1

A score of 4 or more is likely accurate, 2.5 or more plausible, below that weak evidence. A report that conflicts with another, or names a company not listed yet, is held below likely accurate until a person looks.

A person decides. The score ranks reports; it never applies one. Someone checks the evidence of each report, labels it accepted or rejected, and an accepted one becomes an override in the next build: a statement of its own (tier 0) with its reason and the issue it came from. The statements it overrules stay on the release's evidence page, so a correction can always be traced and undone.