Wikimedia Brasil’s Development Best Practices Framework: technical sustainability as an organizational responsibility

In 2025, the Wikidata Query Service went through a split of its graph. The service runs on Blazegraph and had grown past 16 billion triples, adding roughly 1 billion per year. The change was meant to ensure the service’s scalability and stability in the medium term. As an emergency measure to prevent a catastrophic failure, the SPARQL endpoint was split in two: one containing only scholarly articles and another with the rest of Wikidata. The split took effect in May 2025, and queries that need to cross both graphs now require SPARQL federation.

As a result, many queries and tools broke, and many are still not working today. Scholia is the most visible example. The impact was so significant that its maintainers ended up migrating the full graph to a QLever engine, outside Wikimedia infrastructure.

More recently, just a few weeks ago in early September, it was Wikimedia Commons’ turn. The links tables were moved from the s4 database cluster to the new x4 cluster and stopped being updated on s4, which had grown too large to operate efficiently. The change brought down, in the very first week of the contest, the tool that all Wiki Loves Monuments organizers use to track participants and statistics.

These were justified technical decisions, but they show how a tool can stop working without anyone touching its code. When that happens, the question is always the same: who notices the change in time, who understands the code, and who can fix it? If the documentation is outdated or scattered across several links, if it is unclear who maintains the tool, or if the necessary knowledge left along with the last person who worked on it, the answer may be “no one.” This is a risk any tool faces, including those we maintain at Wikimedia Brasil, such as SARA, GLAMWiki Brasil, the Capacity Exchange, and QuickStatements 3.0. And the risk grows with the number of people who use a tool and with how deeply it is embedded in Wikimedians’ workflows.

It was with these and other risks and questions in mind that we built Wikimedia Brasil’s Development Best Practices Framework (ABPD, from its Portuguese acronym). It is a public document, written collaboratively and delivered as part of our 2026 Activity Plan, that seeks to establish a common foundation for the organization’s technical and programmatic development.

In writing it, we recognized that writing “best practices” is not neutral: whoever takes on that role risks exporting their own habits as if they were universal. That is why the framework does not try to reinvent what the movement has already established. The MediaWiki development guidelines, the Toolforge rules, the Wikimedia Foundation Privacy Policy, and the Universal Code of Conduct remain the starting point.

The content grew out of an internal survey of repositories and tools and structured interviews with staff members, contractors, and volunteers: four synchronous conversations and one written response. Several themes came up independently across different accounts: fragmented documentation, difficulty finding out what already exists, unclear paths to contribution, difficulty retaining maintainers, and communication gaps between those who develop and those who use. These themes directly shaped the document’s recommendations.

Eight principles guide decisions when specific guidelines do not cover a concrete case. Among them are open by default, privacy from the start, documentation as a deliverable, and redundancy: no critical system or knowledge should depend on a single person. Sustainability before innovation, reuse before rebuilding, accessibility, and alignment with the movement complete the list.

In practice, the framework sets out concrete commitments:

• A record of the external tools we depend on: notes each tool’s criticality level, the history of changes that have already affected us, whether alternatives exist, and who keeps track of changes.
• A public tool catalog: to answer two questions before any technical decision: “does this already exist?” and “whom do I ask?”.
• Documentation accessible from a single point: with a visible last-review date, the contact of the person responsible, and deployment configuration recorded in the repository itself.
• A self-assessment checklist: evaluates each tool against criteria such as licensing, testing, credentials, accessibility, and privacy.
• A full life cycle for every project: including a sunset plan, so we do not accumulate zombie tools.
• Data protection: a section aligned with Brazil’s General Data Protection Law (LGPD), with personal data mapping and impact reports when needed.
• AI in development: disclosure of the use of artificial intelligence tools in development and maintenance, a preference for open-source or open-weight tools, and a ban on entering sensitive data into these platforms.

The framework is not final. It will be reviewed every strategic cycle. The document also recommends creating a standing committee, with voluntary participation from the organization’s own members, to oversee its implementation.

We also wrote it with other affiliates in mind, especially from the Global Majority, who face similar challenges of technical capacity and small teams. If your affiliate would like to adapt it, simply replace the examples and scale with your own and keep the principles as a starting point.

The full document is available on Meta-Wiki, in Portuguese and English.