Connect with us

Corrections Policy

The obligation

Errors are inevitable in any publication that publishes daily. What is not inevitable is how they are handled, and at WinAddons the handling is fixed: the record is repaired in the open, fast, and without resentment towards whoever pointed out the mistake. A reader who finds an error we have left uncorrected has learned something about every other article on the site. On a beat where people approve updates, buy hardware, plan migrations and patch systems on the strength of what they read, that is not a matter of manners. It is the job itself.

Three labels, three meanings

We use three labels and keep them apart.

  • Correction. A factual error is being repaired: a wrong KB or build number, a wrong CVE identifier, a misread service level agreement, a wrong price or date, a feature pinned to the wrong product or tier, a quotation that was not what the person said. The article is fixed and carries a note recording what was wrong and what is now right. Nothing is quietly rewritten in the hope that nobody kept a copy, and the note stays for as long as the article does.
  • Clarification. The wording was accurate but could mislead. On this beat that usually means status or channel: a feature called available when it was rolling out to a fraction of tenants, an Insider build reported without its channel, a roadmap target that read like a ship date, a consumer change described as if it reached commercial customers. The facts held; the precision did not, and a clarification note says so.
  • Update. Events moved after publication: Microsoft revised the KB article, added a known issue, pulled or reissued the update, patched the flaw, changed the price or answered the question we had asked. Updates are dated and added to the article. A story that was right on the day is not corrected for having been written before the world changed; it is updated so that whoever reads it later is not misled by a faithful account of an earlier moment.

Typos and formatting fixes that leave the meaning untouched are made without a note. If you believe a change we treated as cosmetic altered the meaning, tell us and a note will be added.

A note or a rewrite

Most errors get a note. The wrong figure is replaced in the body of the story, and the note, placed at the top for anything a reader might have acted on and at the end for minor matters, states the original wording, the corrected wording and the date and time of the change. We do not leave the wrong figure standing with the right one appended beneath it.

A rewrite happens when the premise was wrong: the update we said was broken was working and the failure was ours, the feature we said was retired was renamed, the leak we reported was a hoax. In those cases the story is either withdrawn and replaced by an editor’s note explaining what was published and why it was withdrawn, or rewritten with a prominent note at the top describing the original claim and what changed. Either way, the fact that we got it wrong remains visible. A wrong headline is treated as a serious error in its own right, because headlines travel further than stories, and the note says that the headline was changed.

How to report an error

Email support@winaddons.com, put CORRECTION first in the subject line, and include the article’s link, the passage you dispute and the reason you dispute it. The most persuasive reports point at a primary source: the KB article, the build’s release notes, the advisory, the store listing, the SLA document, the filing. Anyone may report an error, whether or not the story affects them; the reader who spotted that we had swapped two builds with nearly identical numbers, or two products with nearly identical names, has done us a favour. Objections to tone, emphasis or framing that stop short of alleging a factual error are handled as complaints rather than corrections: they go to the same address, and an editor uninvolved in the story reads and answers them.

What happens next, and how fast

  • Every correction report is read on the day it arrives, and acknowledged the same day.
  • An editor tests the claim against the sources the story was built on and against whatever you sent. If the question is what Microsoft’s document says, we reread the document; if it is what a build does, we go back to the machine.
  • If you are right, the article is corrected, the note goes on, and you hear from us. Plain factual errors are usually repaired within hours, and never later than one business day after verification.
  • Where the error travelled through our social channels or feeds, the correction follows it there.
  • If we conclude the story was right, we tell you why, with the sources, and you are free to reply with more.
  • If the truth cannot be settled quickly, the disputed passage is qualified or flagged as disputed while we investigate, rather than left standing as fact. Disputes that wait on a reply from Microsoft, or on a document we do not yet hold, can run for days, and when they do, you are kept informed of where things stand.

Errors we treat as urgent

Certain errors go to the front of the queue because a reader acting on them could be harmed: wrong mitigation steps or affected versions in a security story, a workaround capable of breaking a system, a wrong end-of-support date, a wrong price or release date, a data-loss risk misdescribed, and the misidentification of a person or a company. Such reports are examined the moment they are seen, the note goes at the top however small the fix looks, and where a person or organisation has been misidentified we contact them directly if we can.

Lines we do not cross

  • We do not take down accurate reporting because a company, a studio or an executive would prefer it gone. Accurate reporting is a record, and deleting it quietly falsifies the record. Removal happens only in the rare case where the law demands it or where an article is wrong past repair, and in the second case a note records that the article existed and why it went.
  • We do not let money near the record. No payment, no advertising and no promise of either changes what a correction says, and the wall described on our ownership and funding page stands at full height here.
  • We do not penalise a writer for reporting their own mistake. Punishing honesty buys silence, and silence is how small errors become large ones.

The correction log

Each correction and clarification goes into an internal log: the story, the mistake, the fix, who reported it and when. The log is reviewed at intervals for patterns, because an error that keeps recurring, transposed build numbers, say, or a rollout status misread, is a process failure rather than bad luck, and process failures are fixed in the process. A number of rules in our fact-checking policy are there because the log demanded them. If you see something wrong, say so. You will not be argued with for the sake of it, and if you are right, the page will show it.