Grants:Programs/Wikimedia Community Fund/Rapid Fund/Arewa Wikimedia Hackathon Building Wikidata Tools in Northern Nigeria (ID: 23724406)
Applicant details
[edit]- Main Wikimedia username. (required)
JosefAnthony
- Organization
N/A
- If you are a group or organization leader, board member, president, executive director, or staff member at any Wikimedia group, affiliate, or Wikimedia Foundation, you are required to self-identify and present all roles. (required)
N/A
- Describe all relevant roles with the name of the group or organization and description of the role. (required)
Main proposal
[edit]- 1. State the title of your proposal. This will also be the Meta-Wiki page title.
Arewa Wikimedia Hackathon Building Wikidata Tools in Northern Nigeria
- 2. and 3. Proposed start and end dates for the proposal.
2026-04-10 - 2026-06-10
- 4. What is your tech project about, and how do you plan to build the product?
Include the following points in your answer:
- Project goal and problem you solve
- Product strategy or project roadmap
- Technical approach (infrastructure, tech stack, key tools and services)
- Integrations or dependencies (if any)
Project goal and problem
This project pilots the Arewa Wikimedia Hackathon as a regional, in-person technical program for Northern Nigeria. It brings together Arewa developers and experienced Wikimedian contributors to collaboratively improve, extend, and maintain open-source tools built on Wikidata and the Wikimedia technical ecosystem.
Many Wikimedia tools that support open knowledge, cultural heritage discovery, copyright awareness, and content completeness depend on a small group of maintainers and lack sustained contributions from underrepresented regions. At the same time, technically skilled contributors in Northern Nigeria often have limited access to structured pathways into Wikimedia technical work. This project addresses both gaps by creating a Wikimedia Hackathon–style environment where participants can contribute code to real projects, learn the ecosystem, and become long-term contributors.
The hackathon will focus on improving and maintaining existing community tools, including:
- Wikidata Reference Validator – enhancing detection of broken or outdated sources, usability, and extensibility. [1]
- Paulina – a multilingual Toolforge application that supports cultural heritage discovery and copyright/public-domain awareness using Wikidata. [2]
- Clarity Tool – a cross-project tool that identifies missing or incomplete content on Wikipedia, Wikidata, and Wikimedia Commons and suggests structured data to fill gaps. [3]
Although these tools serve different use cases, they share common technical challenges: maintenance, documentation, performance, localization, and the need for new contributors. This project builds a sustainable regional contributor base to address those challenges.
Product strategy and project roadmap
The project is structured as a focused, repeatable hackathon program with clear, achievable technical outputs:
- Preparation phase
- Identify concrete improvement tasks for each tool (features, bugs, performance, documentation).
- Create or review issues and Phabricator tasks under the Engineering-Community project.
- Prepare onboarding materials covering Wikidata APIs, Toolforge, and each tool’s architecture.
- Identify concrete improvement tasks for each tool (features, bugs, performance, documentation).
- Create or review issues and Phabricator tasks under the Engineering-Community project.
- Hackathon implementation
- Technical orientation on the Wikimedia technical ecosystem (Wikidata, Toolforge, SPARQL, APIs).
- Tool demonstrations and code walkthroughs.
Team-based hacking on defined tasks, including:
- Feature development and bug fixes.
- Usability, performance, and accessibility improvements.
- Enhancements for cultural heritage discovery and copyright logic (Paulina).
- Improvements to detecting missing content and structured-data reuse (Clarity).
- Validation logic and interface improvements (Reference Validator).
- Documentation and contributor guides.
- Testing and submission of contributions via pull requests or patches.
- Technical orientation on the Wikimedia technical ecosystem (Wikidata, Toolforge, SPARQL, APIs).
- Tool demonstrations and code walkthroughs.
- Team-based hacking on defined tasks, including:
- Feature development and bug fixes.
- Usability, performance, and accessibility improvements.
- Enhancements for cultural heritage discovery and copyright logic (Paulina).
- Improvements to detecting missing content and structured-data reuse (Clarity).
- Validation logic and interface improvements (Reference Validator).
- Post-event consolidation
- Review and merge accepted contributions.
- Publish updated documentation.
- Support participants to continue contributing after the event.
- Review and merge accepted contributions.
- Publish updated documentation.
This roadmap ensures immediate software improvements while establishing the Arewa Wikimedia Hackathon as a repeatable regional program aligned with the global Wikimedia Hackathon model.
Technical approach (infrastructure, stack, tools)
The project focuses on improving existing Wikimedia infrastructure rather than building new platforms.
- Tools in scope
- Wikidata Reference Validator: improvements to validation logic, UI/UX, performance, and extensibility.
- Paulina (Toolforge): enhancements to copyright and public-domain logic, usability, localization, and documentation.
- Clarity Tool (Toolforge): improvements to identifying missing information, structured-data suggestions, reporting, and user experience.
- Wikidata Reference Validator: improvements to validation logic, UI/UX, performance, and extensibility.
- Paulina (Toolforge): enhancements to copyright and public-domain logic, usability, localization, and documentation.
- Infrastructure and stack
- Hosting: Wikimedia Toolforge / Wikimedia Cloud Services
- Data access: Wikidata APIs and SPARQL Query Service
- Version control: GitHub/GitLab repositories for each tool
- Issue tracking: Wikimedia Phabricator
- Documentation: Meta-Wiki tool pages and repository documentation
- Hosting: Wikimedia Toolforge / Wikimedia Cloud Services
- Data access: Wikidata APIs and SPARQL Query Service
- Version control: GitHub/GitLab repositories for each tool
- Issue tracking: Wikimedia Phabricator
All development will follow Wikimedia security, privacy, and API usage guidelines, and all code will be released under OSI-approved open-source licenses.
Integrations and dependencies
- Wikidata APIs and SPARQL for structured data access and validation.
- Toolforge environment for hosting, testing, and deployment.
- Existing tool codebases for Paulina, Clarity, and the Wikidata Reference Validator.
- Coordination with current maintainers where required, using established open-source workflows.
The project does not require changes to MediaWiki core or extensions and avoids dependencies that would require review from Wikimedia Foundation engineering, ensuring full compliance with Rapid Fund / Tech guidelines.
- 5. What is the expected impact of your project, and how will you measure success?
Include the following points in your answer:
- Milestones and progress tracking
- Project impact and success metrics
Project impact
The Arewa Wikimedia Hackathon is designed to create both immediate technical improvements and long-term capacity within the Wikimedia technical community in Northern Nigeria.
Short-term impact
- Improvements to existing Wikimedia tools (Wikidata Reference Validator, Paulina, and Clarity), including new features, bug fixes, performance enhancements, and documentation updates.
- Increased quality, accessibility, and usability of tools that support open knowledge, cultural heritage discovery, copyright awareness, and content completeness across Wikimedia projects.
- Onboarding of new contributors who gain hands-on experience with Wikidata APIs, Toolforge, SPARQL, and open-source collaboration workflows.
Long-term impact
- Establishment of a sustainable regional Wikimedia Hackathon program in Northern Nigeria that mirrors the global Wikimedia Hackathon model.
- Growth of a local technical community capable of maintaining and extending Wikimedia tools beyond the funded period.
- Increased representation of underrepresented communities and languages in Wikimedia technical development.
- Stronger integration between local developer initiatives and global Wikimedia technical efforts.
Milestones and progress tracking
The project will be tracked through clear, time-bound milestones:
- Pre-hackathon preparation
- Define technical tasks and feature goals for each tool.
- Create or review Phabricator tasks and repository issues.
- Publish onboarding materials and hackathon agenda.
- Define technical tasks and feature goals for each tool.
- Create or review Phabricator tasks and repository issues.
- Hackathon delivery
- Conduct technical training sessions.
- Complete planned development sprints.
- Submit code contributions (pull requests, patches, or commits).
- Document outcomes and demos.
- Conduct technical training sessions.
- Complete planned development sprints.
- Submit code contributions (pull requests, patches, or commits).
- Post-hackathon consolidation
- Review and merge accepted contributions.
- Publish updated documentation and contributor guides.
- Follow up with participants for continued involvement.
- Review and merge accepted contributions.
- Publish updated documentation and contributor guides.
Tracking methods
- Wikimedia Phabricator for task management and progress reporting.
- GitHub/GitLab repositories for tracking commits, pull requests, and issues.
- Event documentation on Meta-Wiki (agenda, outcomes, and final report).
Project impact and success metrics
Success will be measured using both quantitative and qualitative indicators:
Technical output
- Number of pull requests, patches, or commits submitted.
- Number of features added, bugs fixed, or performance improvements implemented.
- Documentation updates published (README files, tool pages, contributor guides).
Community capacity
- Number of participants trained during the hackathon.
- Number of first-time technical contributors to Wikimedia tools.
- Number of participants who continue contributing after the event.
Tool-level impact
- Adoption or testing of new features by users or maintainers.
- Reduction in reported issues related to usability, data completeness, or reliability.
- Feedback from tool maintainers and Wikimedia technical community members.
Program sustainability
- Continued activity in Phabricator tasks and repositories after the event.
- Plans for follow-up hackathons or technical meetups under the Arewa Wikimedia Hackathon program.
- Evidence of local contributors taking ownership of ongoing maintenance tasks.
Together, these metrics ensure that the project delivers tangible technical improvements while building a sustainable regional contributor base for the Wikimedia technical ecosystem.
- 6. Who is your target audience, and how have you confirmed there is demand for this project? How did you engage with the Wikimedia community?
Include the following points in your answer:
- Project demand and target audience description
- Links to interaction(s) with Wikimedia community
- Evidence from community consultation such as the [Community Wishlist]
Project demand and target audience
The primary target audience for this project is Arewa (Northern Nigerian) developers and technically inclined Wikimedians who are interested in contributing to Wikimedia’s technical ecosystem but currently have limited access to structured, hands-on technical events. This includes:
- Local software developers with open-source experience who want to contribute to Wikimedia projects.
- Wikimedians with technical interests in Wikidata, Toolforge, bots, gadgets, and data tools.
- Contributors interested in cultural heritage, copyright/public-domain discovery, and improving content completeness across Wikimedia projects.
- Multilingual contributors working in underrepresented languages and regions.
There is strong demand for this project because many Wikimedia technical tools depend on a small number of maintainers, while regional technical communities—especially in Africa—remain underrepresented in Wikimedia development spaces. At the same time, editors and contributors consistently raise issues around data completeness, structured data reuse, copyright awareness, and tool usability. This project directly responds to those needs by improving existing tools (Wikidata Reference Validator, Paulina, and Clarity) and expanding the contributor base that can maintain them.
Links to interaction with the Wikimedia community
Demand for this project has been confirmed through ongoing engagement with Wikimedia technical and community spaces, including:
Existing tool development and feedback
Wikidata Reference Validator (project and community feedback): [4]
Paulina Toolforge: https://gitlab.wikimedia.org/toolforge-repos/paulina
Clarity Tool: [5]
'
Wikimedia technical workflows
Use of Wikimedia Phabricator for tracking issues, feature requests, and development tasks related to these tools:https://phabricator.wikimedia.org/project/board/8311/
[6]
Local and regional community discussions
Engagement with Wikimedian developers and user groups through community channels, meetups, and planning discussions for a regional hackathon initiative. These discussions were primarily conducted through community Telegram and WhatsApp groups.
These interactions demonstrate that there is both technical demand for improvements to these tools and strong community interest in participating in a structured hackathon format.
- 7. How will your team predict and manage potential user security and privacy risks, and what risks do you currently see?
Include the following points in your answer:
- The level of in-house or consulted security and privacy expertise you will have available to you during delivery of this project
- How your development, testing, and deployment processes mitigate the introduction of unnecessary security or privacy risks
Security and privacy expertise
The project is led by JosefAnthony a developer with prior experience building and maintaining Wikimedia tools, including a previously funded Rapid/Tech project hosted in the Wikimedia technical ecosystem. This experience includes working within Wikimedia Toolforge, Wikidata APIs, and open-source development workflows that already enforce security and privacy best practices.
In addition to in-house experience:
- The project will follow Wikimedia Foundation security, privacy, and API usage guidelines.
- Existing tool maintainers (for Paulina, Clarity, and the Wikidata Reference Validator) and the wider Wikimedia technical community provide peer review through established open-source contribution processes.
- Task tracking and technical discussions will be conducted through Wikimedia Phabricator and public repositories, enabling transparency and community oversight.
This combination of hands-on technical experience, platform-level safeguards, and community review provides appropriate security and privacy expertise for the scope of this project.
Risk identification and mitigation
The project focuses on improving existing tools that operate on public Wikimedia data. No collection of sensitive personal data is required. The main risks identified are therefore limited and manageable:
- Misuse of APIs or excessive requests
- Risk: Overloading services or violating API usage guidelines.
Mitigation:
- Follow Wikimedia API and Toolforge usage policies.
- Use rate-limiting, caching, and efficient queries (SPARQL best practices).
- Test features in development environments before deployment.
- Risk: Overloading services or violating API usage guidelines.
- Follow Wikimedia API and Toolforge usage policies.
- Use rate-limiting, caching, and efficient queries (SPARQL best practices).
- Introduction of bugs or vulnerabilities through new code
- Risk: New features could unintentionally create security issues or service instability.
Mitigation:
- All changes will be submitted via pull requests or patches for review.
- Code will be tested locally and on Toolforge staging where applicable.
- Use of established libraries and existing project architectures.
- Clear separation between development, testing, and production deployment.
- Risk: New features could unintentionally create security issues or service instability.
- All changes will be submitted via pull requests or patches for review.
- Code will be tested locally and on Toolforge staging where applicable.
- Use of established libraries and existing project architectures.
- Handling of user data
- Risk: Accidental collection or exposure of personal data.
Mitigation:
- Tools will only process public Wikidata and Wikimedia project content.
- No authentication credentials, private user data, or personally identifiable information will be collected or stored.
- Logs will be limited to technical diagnostics and will not include user-identifying information.
- Risk: Accidental collection or exposure of personal data.
- Tools will only process public Wikidata and Wikimedia project content.
- No authentication credentials, private user data, or personally identifiable information will be collected or stored.
- Privacy or compliance issues
- Risk: Non-compliance with Wikimedia privacy or platform policies.
Mitigation:
- Adherence to the Wikimedia Foundation Privacy Policy, Toolforge Terms of Use, and security guidelines.
- Avoidance of features that would require a formal security review from WMF.
- Prompt response to any issues flagged by maintainers or community reviewers.
- Risk: Non-compliance with Wikimedia privacy or platform policies.
- Adherence to the Wikimedia Foundation Privacy Policy, Toolforge Terms of Use, and security guidelines.
- Avoidance of features that would require a formal security review from WMF.
Secure development, testing, and deployment practices
- Development:
- Use open-source repositories with version control.
- Apply code reviews and follow existing coding standards for each tool.
- Use open-source repositories with version control.
- Testing:
- Test new features in development environments before deployment.
- Validate API usage and ensure queries are optimized and compliant.
- Test new features in development environments before deployment.
- Deployment:
- Deploy only to Wikimedia Toolforge / Cloud Services, which provides built-in infrastructure security and monitoring.
- Roll out changes incrementally and monitor for errors or regressions.
- Deploy only to Wikimedia Toolforge / Cloud Services, which provides built-in infrastructure security and monitoring.
- Documentation and transparency:
- Document features, configuration, and limitations clearly.
- Maintain public issue trackers so problems can be identified and addressed quickly.
- Document features, configuration, and limitations clearly.
- 8. Who is on your team, and what is your experience?
Include the following points in your answer:
- Your experience as a developer, relevant past projects
- Wikimedia SUL (developer), Gerrit, Github, Gitlab or other relevant public account handles
- Other team members, their roles and expertise
Lead organizer / developer: JosefAnthony
The project is led by me as the principal developer and organizer. Experienced Wikimedian developers and contributors will be invited to support mentoring, technical sessions, and code reviews during the hackathon.
Relevant experience and past projects
- Wikidata Reference Validator – Lead developer of a Rapid/Tech-funded tool that checks and flags broken, outdated, or unreliable external sources on Wikidata. I handle architecture, API integration, and ongoing maintenance.
- Wikimedia Hackathon 2025 (Istanbul) – Awardee and active participant, contributing to technical projects and collaborating with the global Wikimedia developer community.
- Wikimania 2025 Scholarship Recipient – Participated in the Wikimania Hackathon, working on Wikimedia technical initiatives and engaging with maintainers and contributors.
- Experience deploying and maintaining tools on Wikimedia Toolforge / Cloud Services, working with Wikidata APIs, SPARQL, and open-source workflows.
Public technical profiles
Phabricator: [8]
Gerrit: [9]
GitLab: [10]
These accounts reflect my public technical contributions and ongoing work within the Wikimedia ecosystem.
Other team members and roles
Arewa Wikimedian Developers (Participants and Mentors): Local developers and contributors who will support tool development, onboarding, and post-event follow-up during the hackathon.
- 9. How will the project be maintained long-term?
Include the long-term maintenance plan with maintainer(s) in your answer. If you expect the long-term maintenance to incur expenses, please list those and the plan for long-term expense coverage.
Long-term maintenance approach
This project focuses on improving and sustaining existing Wikimedia tools rather than creating new platforms. Long-term maintenance will therefore be integrated into established open-source workflows and community structures.
- Wikidata Reference Validator will continue to be maintained by me as the lead developer, building on my existing Rapid/Tech-funded work. I will remain responsible for reviewing contributions, fixing bugs, and coordinating future improvements.
- Paulina and Clarity Tool will continue to be maintained by their respective maintainers. Contributions produced during the hackathon will be submitted through standard pull request or patch workflows and maintained within their existing repositories.
The hackathon is designed to expand the contributor base, onboarding Arewa developers who can continue contributing to these tools beyond the funded period, reducing reliance on a single maintainer.
Community-based sustainability
To support long-term sustainability:
- Participants will be introduced to each tool’s codebase, contribution guidelines, and issue trackers.
- Documentation and contributor guides will be improved to lower the barrier for future contributors.
- Phabricator tasks will remain open after the event to encourage continued participation.
- The Arewa Wikimedia Hackathon will serve as a repeatable program, enabling follow-up hackathons or meetups using the same structure.
This approach ensures maintenance is distributed across a community rather than dependent on ongoing grant funding.
Long-term costs and expense coverage
The tools involved are hosted on Wikimedia Toolforge / Cloud Services, which does not require direct hosting or infrastructure payments from the project team.
- There are no expected ongoing infrastructure costs after the grant period.
- Maintenance work will primarily involve volunteer time and community contributions
- 10. Under what license will your code be released, and how will you ensure the product is well documented?
Include the following points in your answer:
- Code license and compatibility with Wikimedia projects
- Documentation plan
Code license and compatibility
All code produced or modified as part of this project will be released under OSI-approved open-source licenses that are fully compatible with Wikimedia projects and policies.
- Improvements to the Wikidata Reference Validator, Paulina, and Clarity Tool will follow the existing licenses used by each project to ensure compatibility and continuity.
- Where new code is introduced, it will use a permissive open-source license commonly used within the Wikimedia ecosystem (such as MIT or GPL-compatible licenses), in line with Wikimedia and Toolforge requirements.
- On-wiki code and configuration will follow local wiki licensing policies where applicable.
This approach ensures all contributions can be reused, reviewed, and maintained by the Wikimedia community without legal or compatibility concerns.
Documentation plan
Documentation is a core component of this project and will be improved alongside code contributions.
The documentation plan includes:
- Updating README files in the relevant repositories to explain tool purpose, setup, and contribution workflows.
- Adding developer onboarding documentation, including environment setup, API usage, and common contribution tasks.
- Documenting new features and changes introduced during the hackathon.
- Ensuring documentation is written clearly and is accessible to new contributors, including those from underrepresented communities.
All documentation will be publicly available, version-controlled, and maintained alongside the code to support long-term sustainability.
- 11. Will your project depend on or contribute to third-party tools or services?
The project does not depend on external third-party commercial services. All development and deployment will take place within the Wikimedia technical ecosystem.
The project contributes to existing Wikimedia community tools, including:
- Wikidata Reference Validator (hosted on Wikimedia Toolforge)
- Paulina (hosted on Wikimedia Toolforge)
- Clarity Tool (hosted on Wikimedia Toolforge)
These tools are open-source, community-maintained, and built specifically for Wikimedia projects. Contributions will be made through their existing repositories and contribution workflows.
Repos:
- 12. Is there anything else you’d like to share about your project? (optional)
I have shared early plans for this project with members of the Wikidata technical community in Germany, who are aware of the initiative and open to further discussion if deeper collaboration becomes relevant.
Budget
[edit]- 13. Upload your budget for this proposal or indicate the link to it. (required)
- 14. and 15. What is the amount you are requesting for this proposal? Please provide the amount in your local currency. (required)
1384890 NGN
- 16. Convert the amount requested into USD using the Oanda converter. This is done only to help you assess the USD equivalent of the requested amount. Your request should be between 500 - 5,000 USD.
1000 USD
- By submitting your proposal/funding request you confirm that you have read and agree to the Application Privacy Statement, WMF Friendly Space Policy, and the Universal Code of Conduct.
Yes
Endorsements and Feedback
[edit]Please add endorsements and feedback to the grant discussion page only. Endorsements added here will be removed automatically.
Community members are invited to share meaningful feedback on the proposal and include reasons why they endorse the proposal. Consider the following:
- Stating why the proposal is important for the communities involved and why they think the strategies chosen will achieve the results that are expected.
- Highlighting any aspects they think are particularly well developed: for instance, the strategies and activities proposed, the levels of community engagement, outreach to underrepresented groups, addressing knowledge gaps, partnerships, the overall budget and learning and evaluation section of the proposal, etc.
- Highlighting if the proposal focuses on any interesting research, learning or innovation, etc. Also if it builds on learning from past proposals developed by the individual or organization, or other Wikimedia communities.
- Analyzing if the proposal is going to contribute in any way to important developments around specific Wikimedia projects or Movement Strategy.
- Analysing if the proposal is coherent in terms of the objectives, strategies, budget, and expected results (metrics).
This is an automatically generated Meta-Wiki page. The page was copied from Fluxx, the web service of Wikimedia Foundation Funds, where the user has submitted their application. Please do not make any changes to this page because all changes will be removed after the next update. Use the discussion page for your feedback. The page was created by CR-FluxxBot.