Profile
Name: Olamide Peter Ojo
Email: peterojoolamide@gmail.com
Location: Nigeria
Timezone: WAT (UTC +1)
Project Title
Addressing the Lusophone Technological Wishlist Proposals
Synopsis
The Lusophone Technological Wishlist is a community-driven effort aimed at identifying the most important technical improvements needed by contributors working on Portuguese-language Wikimedia projects. These improvements are focused on making editing, contributing, and organizing activities easier and more efficient for editors, readers, and researchers.
This project aligns with the broader goals of the Wikimedia Foundation to improve contributor experience and reduce barriers to participation.
For this internship, I will focus primarily on Wishlist #8: adding Wikidata support to the WikiScore tool. WikiScore is widely used in edit-a-thons and contests to track contributions, but it currently only supports Wikipedia edits. This creates a gap, as contributions made on Wikidata are not counted, even though they are an important part of the Wikimedia ecosystem.
By extending WikiScore to include Wikidata contributions, organizers will be able to run more inclusive and accurate contests without relying on manual tracking.
As a secondary goal, if time permits, I will explore Wishlist #3, which focuses on improving the editing experience in the VisualEditor by detecting duplicate references and encouraging reuse.
Problem
Limited Support for Wikidata Contributions
Currently, WikiScore only tracks edits made on Wikipedia. This means:
- Contributions to Wikidata (such as adding statements or labels) are ignored
- Organizers must manually track or estimate these contributions
- Contributors focused on structured data are under-recognized
This creates friction during edit-a-thons and reduces motivation for contributors working on Wikidata.
Why This Matters
Wikidata is becoming increasingly important in the Wikimedia ecosystem. Many contributors, especially newer ones, start with structured data tasks because they are more accessible than writing full articles.
Without proper tooling support:
- Organizers face extra workload
- Results are less accurate
- Some contributions go unnoticed
Improving WikiScore to support Wikidata directly addresses these issues.
Proposed Solution
The goal is to extend WikiScore so it can:
- Fetch user contributions from Wikidata using available APIs
- Process and categorize different types of edits (e.g., labels, statements, references)
- Assign scores based on contribution type
- Display Wikidata contributions alongside Wikipedia edits in a unified view
This will involve:
- Building a Python-based integration with the Wikidata API
- Designing a clear scoring system for different edit types
- Ensuring the system remains reliable even with large numbers of users
Technical Approach
To keep things simple and maintainable:
- 1. Data Retrieval
- Use Wikidata APIs to fetch user contributions within a given timeframe
- Handle pagination, rate limits, and inconsistent responses
- 2. Data Processing
- Convert raw API responses into a structured format
- Identify meaningful contribution types (e.g., adding claims vs minor edits)
- 3. Scoring System
- Define clear and fair scoring rules
- Ensure the system is easy to adjust in the future
- 4. Integration with WikiScore
- Extend the backend to include Wikidata contributions
- Update the interface to display combined results
- 5. Testing & Reliability
- Test with real edit-a-thon scenarios
- Ensure performance remains stable at scale
Proposed Timeline
Weeks 1–2: Getting Oriented and Understanding the Problem
- Set up the development environment and make sure Wikiscore runs locally
- Get familiar with how Wikimedia Foundation projects work, especially Wikidata and Wikiscore
- Study how Wikiscore currently tracks and scores Wikipedia edits
- Explore the Wikidata APIs to understand what kind of contribution data is available
- Define a clear plan for adding Wikidata support to Wikiscore
Weeks 3–4: Breaking Down the Work and Early Experiments
- Identify what types of Wikidata contributions should be counted (e.g., labels, statements, references)
- Build Python scripts to fetch user contributions from Wikidata
- Experiment with parsing and structuring this data in a way Wikiscore can use
- Share early findings and approach with mentors for feedback
Weeks 5–6: Core Implementation
- Start integrating Wikidata contribution fetching into Wikiscore
- Implement logic to process and store contributions in a consistent format
- Begin defining how different types of edits should be scored
- Write initial tests to ensure data is being collected correctly
Weeks 7–8: Scoring Logic and System Integration
- Finalize scoring rules for Wikidata contributions
- Integrate these scores into Wikiscore’s existing system
- Ensure results are clearly displayed alongside Wikipedia edits
- Improve reliability by handling edge cases (e.g., incomplete data, API limits)
Weeks 9–10: Testing and Refinement
- Test the system with real or simulated edit-a-thon data
- Fix bugs and improve performance where needed
- Refine how results are presented so they are easy to understand for organizers
- Gather feedback and make adjustments
Weeks 11–12: Finalization and Documentation
- Write clear documentation explaining:
- How Wikidata scoring works
- How to use the updated Wikiscore tool
- Clean up the codebase and ensure it meets contribution standards
- Prepare final deliverables (PRs, demo, report)
- Address final feedback from mentors and the community
If time permits, I would explore parts of Wishlist #3, which has to do with duplicate reference detection in VisualEditor
After the Internship
My goal is to continue contributing to Wikimedia beyond this project. I plan to:
- Maintain and improve the Wikidata integration in WikiScore
- Support organizers using the tool
- Continue contributing to related tools and projects
- Explore Wishlist #3
Microtask T418285: https://github.com/olamidepeterojo/Outreachy-Wiki
Microtask T418286: https://github.com/olamidepeterojo/Outreachy-Wikimedia