Editorial Standards & Ethics

Why a Microsoft news site needs written rules

Covering a company this size means working in a loud room. Microsoft publishes more about itself in a week than a newsroom could read in a month, partners and vendors turn out marketing dressed as analysis, and a screenshot of a hidden feature flag can circle the world before anyone has asked whether the feature works. WinAddons draws the obvious conclusion: a beat this dense needs standards that are written down, specific and enforceable by the people who read us. These are ours; where we break them, our corrections policy is the remedy and support@winaddons.com is the complaints desk.

Accuracy comes first

We publish what we have verified. Each fact in a story should trace back to a document, to something observed on a machine we control, or to a source identified by name or by role, and the story should say which. A claim we could not verify is dropped or is described as unverified, in that word. When speed and certainty pull in different directions, the story waits. The verification steps for each section are in our fact-checking policy.

Independence from Microsoft and from everyone else we cover

This is the heart of the document, and it is brief because it has no exceptions.

• WinAddons is not affiliated with, endorsed by or sponsored by Microsoft. We are not a Microsoft partner, reseller or affiliate, and we belong to no Microsoft programme that places conditions on coverage.
• Nobody who writes or edits here takes undisclosed payment, gifts worth anything, equity, a share of revenue, subscriptions beyond the span of a review, or any other consideration from Microsoft or from any studio, hardware maker, software vendor, reseller or consultancy in its orbit. No sum is small enough to be harmless.
• Advertisers buy space and nothing more. Advertising is filled by a network, the identity of advertisers plays no part in editorial planning, and no advertiser sees a story before publication. Sponsored content is labelled so that it cannot pass for news; sponsors have no say in coverage, no preview of stories about them and no protection from those stories; our ownership and funding page has the details.
• Anyone writing business coverage does not trade Microsoft securities, or those of companies named in their stories, around the time of that coverage, and discloses their holdings to an editor. Anyone with a personal stake in a story’s subject stays away from that story.

Sourcing and attribution

The document beats the description of the document. We read the release notes, the KB article, the advisory, the SLA, the filing and the documentation before we characterise any of them, and we name them in the story so that readers can go and look. A quoted person is identified, along with the capacity in which they spoke. Vague attributions such as sources say, with nothing more, do not appear on this site.

Anonymity is granted only when the information matters, cannot be had on the record, and naming the source would expose them to real harm, a test that employees of Microsoft and its partners frequently meet. An editor must know who the source is and must approve the arrangement. The story says why the source is unnamed and how they come to know what they describe. Anonymity is never a cover for attacking a person or a company without accountability, and never a service to communications staff spinning their own announcement.

Pre-release, rumour and leak reporting

Much of this beat concerns things that have not shipped, and on such stories the label is part of the fact.

• A feature seen in an Insider build is reported as an Insider feature, with the channel and build number named, and with the reminder that Insider features change and are sometimes dropped.
• A feature behind a flag or found by digging through code is reported as unannounced and untested, and the story says how it was found.
• A roadmap entry is a target, reported with its identifier and its status, never as a release date.
• A rumour is called a rumour, a leak is called a leak, and both carry what we know about the provenance and what we could not confirm. Neither is promoted to fact by repetition.
• A store listing, support article or download that appears before an announcement is reported as what it is, with how and when we saw it, and we keep a copy in case it disappears.

Security reporting

We do not publish exploit details, proof-of-concept code or step-by-step reproduction for a vulnerability before a fix is available, and we do not publish details that would materially help an attacker even after one is. We report what Microsoft and researchers have published, which versions are affected, whether exploitation is known, and what to do. Breach victims who have not disclosed the breach themselves are not named unless the public interest is clear and the facts are confirmed, and we do not link to stolen data. Researchers who bring us findings before disclosure are directed to the Microsoft Security Response Center, and we cover the fix once it exists.

Embargoes, briefings and review units

An embargo is an agreement about when, never about what. We keep the embargoes we accept, and we accept them only with the terms in writing beforehand. No embargo limits what we may say, whom we may ask, or whether we may report something we learned independently before the briefing. Briefings offered on condition that their existence stays secret are refused.

Consoles, controllers, devices, games and software lent for review are disclosed in the review, together with how long we had them, the conditions we used them under and whether they went back. A loan does not purchase a verdict. We refuse review units offered on condition that the coverage is favourable, is shown to the lender first or steers clear of any subject. We pay our own way to events wherever possible; where we did not, the story names who paid.

Fairness, headlines and images

Anyone criticised in a story is given a real opportunity to respond before publication, with enough detail and time, and the response is reported fairly and prominently. If someone declines to comment, the story says so; if we could not reach them, it says what we tried. Fairness is not false balance: a claim that the documentation contradicts is reported as contradicted. A headline may not outrun its story or assert as fact something the story only attributes. Screenshots carry the build or version they came from, renders and concept images are labelled as renders and concepts, and we do not manufacture synthetic images of real people or real products and pass them off as photographs.

Automation, plagiarism and accountability

Where software helps with research or production, the responsibility stays human: nothing goes out without editorial review, verification remains tied to primary sources, and every published word is answered for by the masthead, never by a tool. Reporting that began elsewhere is credited to its origin, and rewording an exclusive does not make it ours. Readers who believe we have broken these standards can write to support@winaddons.com. Complaints go to an editor who had no part in the story and are answered in writing, and when the correction log or a complaint shows that a rule needs changing, the change is made on this page.