Jump to content
Gov  ·  Market  ·  Community  ·  Policies  ·  Funding  ·  Open Call  ·  Get started

Policies/en/Data-Publication-Guidelines

From WikiDeal
Revision as of 03:36, 5 July 2026 by AI-Admin-Assistant (talk | contribs) (Migration block 2: create page adapted from Wikimedia Foundation Governance Wiki (CC BY-SA 4.0), proposal to be adopted)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This is a draft version. Source: adapted notably from the Wikimedia Foundation Governance Wiki, https://foundation.wikimedia.org/wiki/Legal:Data_publication_guidelines (CC BY-SA 4.0), with changes. Status: proposal, to be adopted. See the detailed disclaimer.

In simple words: publishing statistics about the platform (how many users, how many contracts signed, in which countries) is useful and transparent, but publishing numbers that are too precise could identify individual people. This page proposes rules for publishing data safely: risk levels, thresholds (for example, never publish a statistic about fewer than 25 users), and a checklist before any publication.

Data publication guidelines

The right to privacy is at the core of how communities would contribute to the WikiDeal platform, and upholding this right is intended to be central to the human rights commitments of the Ynternet.org Foundation. These data publication guidelines describe best practices for managing risk in data publication. They complement the data retention guidelines and the data collection guidelines, and would contribute to the commitment to protect users' data as elaborated in the Privacy policy.

On WikiDeal, aggregated usage statistics are part of the data published by design (for example, how many contracts of a given template were signed). These guidelines propose the thresholds and reviews that would keep such publications safe for individual users.

Data publication risk tiering grid

Data classification Confidential Restricted
Risk level Tier 1: High risk Tier 2: Medium risk Tier 3: Low risk
Data that could certainly be used to cause harm Data that could likely or possibly be used to cause harm Data that is unlikely to be used to cause harm or is private for administrative reasons
Examples (non-exhaustive list)
  • Data containing personally identifiable information (see the Privacy policy)
  • Granular analyses of
    • countries on the country protection list<ref name="cpl">The country protection list would be a reference guide for countries potentially dangerous for internet freedom; it is not indicative of a working relationship with each country. Such a list would be established for WikiDeal.</ref>
    • fundraising data
  • Recurring data releases of medium risk data
  • High-level analyses of
    • countries on the country protection list<ref name="cpl" />
    • fundraising data
  • Granular analyses of
    • countries not on the country protection list
    • Markets and Portals
    • editing data
    • interaction data
    • reading data
  • Recurring data releases of low risk data
  • High-level analyses of
    • countries not on the country protection list
    • Markets and Portals
    • editing data
    • interaction data
    • reading data
  • Any analyses that utilize differential privacy<ref>This process requires specialist help to ensure that the differential privacy algorithm is correctly configured, as well as adequate documentation.</ref>
  • Collations and combinations of already-public data that it may be inconvenient or difficult for external parties to access
Response time goal 3 work weeks 5 work days Not applicable
What this would mean for the teams
Follow-up actions
  • Do not upload this data to servers outside the control of the Ynternet.org Foundation
  • Clear outputs before committing code, even to private repositories
  • The legal and security reviewers would consider publication of high risk data on a case-by-case basis after review and risk mitigation
  • Unsanitized data could be uploaded to private servers outside of the Foundation (private repositories, internal messaging, shared drives)
  • Sanitized data is considered to be low risk, and could be uploaded to public servers (public repositories, presentations, mailing lists). Data sanitization involves
    • clearing all outputs that display raw data
    • filtering out or obfuscating granular analyses as defined by the threshold table below
  • The legal and security reviewers would consider publication of medium risk data on a case-by-case basis after review and risk mitigation
  • This data could be uploaded to public servers (public repositories, presentations, mailing lists)

Frequently asked questions

  • Q: What is the risk tiering grid used for? The risk tiering grid would help teams that work with data know when their work requires privacy review by the legal and security reviewers.
  • Q: What are the key risks the tiering grid measures? The key risks are on both the overuse and underuse ends of the spectrum. If the grid is used in such a way that too many things are triaged to the reviewers, then the review becomes a bottleneck for necessary workflow. On the other hand, if projects go live that would have been halted or mitigated under privacy review, that exposes the Foundation to privacy risks, including reputational, legal and security risks.
  • Q: Who are the intended audiences of the tiering grid? Teams that work with data in product and technology.
  • Q: What is the process for updating the tiering grid or resolving tiering disagreements?
    • Get privacy approval
    • Anyone can initiate an update or amendment, but approval must be sought across the board before implementing
    • Ongoing feedback immediately following launch, regular recalibration thereafter (for example every quarter or half year)
  • Q: What should I do if I am unsure whether to reach out to the reviewers? When in doubt, it is better to err on the side of caution and submit a review request.

Threshold table

Use this table to determine whether an analysis is granular or high-level, informing which tier or risk level the analysis is considered as. Note: thresholds are determined based solely on the statistics being released; if you are only releasing information about edits, you do not need to account for how many contributors generated the edits.

Data unit type Classification of analysis based on counts
"Granular" "High-level"
Users (including unique devices) under 25 25 or more
Edits under 50 50 or more
App interactions under 100 100 or more
Views under 250 250 or more

For reverts, report the rate and a rough total if the reverted edit count or total edit count are less than the threshold. For example:

  • If 8 out of 49 edits were reverted: "16.3% reverted (out of <50 edits)"
  • If 49 out of 49 edits were reverted: "100% reverted (out of <50 edits)"
  • If 20 out of 580 edits were reverted: "3.4% reverted (out of ~600 edits)" or "3.4% reverted (out of >500 edits)"
  • If 50 out of 50 edits were reverted: OK to leave as-is (both counts meet the threshold)

This guidance also applies to reporting below-threshold percentages for other data types.

Publication risk mitigation checklist

This self-service checklist is intended to help data scientists and analysts lower the risk of a high or medium risk data publication, and reduce unintentional disclosures of private information.

Before you post data publicly (which includes pushing a notebook to a public repository), have you:

  • entered this data publication into the data publication log (the concrete logging tool would be defined upon adoption of this proposal)?
  • cleared outputs that display raw data?
  • cleared outputs that display granular data (as defined in the threshold table above)?
  • obfuscated or filtered out rows that display granular data (for example, replacing a count of users below 25 by "<25", or removing rows below the threshold)?

General risk heuristics

Below, "X > Y > Z" means that X is riskier than Y, which is in turn riskier than Z.

  • Data type:
    • Geography:
      • city > (sub-national) region > country > subcontinent > continent > global
      • country protection list > non-country protection list
    • Device details:
      • raw user-agent > browser or OS type > device type
      • raw IP > partially-redacted IP range
    • Temporal:
      • timestamp > hourly > daily > monthly
    • Combinations of multiple keys > any key on its own (for example country + Market > country or Market)
  • User activity type:
    • fundraising activity > contracting activity > editing activity > interaction activity > reading activity
  • Foundation activity type:
    • data collection > data analysis
    • granular analysis > high-level analysis

Contact us

If you think that these guidelines have potentially been breached, or if you have questions or comments about compliance with the guidelines, please contact info@wikideal.net.

Notes

<references />

See also