**Google summer of code 2026 Proposal: Programs & Events Dashboard —System-Wide Metrics & Data Downloads**
| Applicant | `Sharon Mwenda`
| Contact | `smkathambi@gmail.com`
| Github | https://github.com/sharon-kathambi
| Location | `Budapest, Hungary`
| Timezone | `CET/CEST`
| Organization | `Wikimedia Foundation`
| Project | `Programs & Events Dashboard — System-Wide Metrics & Data Downloads`
| Mentors | @Ragesoss, @Abishekdascs
| Duration | `350 hours (Medium) `
1. **Abstract**
The Wikimedia Programs & Events Dashboard (outreachdashboard.wmflabs.org) tracks hundreds of organized editing projects: edit-a-thons, education campaigns, and community programs across the entire Wikimedia ecosystem. But Wikimedia Foundation staff must request system-wide data manually, and the set of metrics exposed to the public is outdated and incomplete.
This project delivers two tightly related improvements:
- A secure, authenticated data-download endpoint (CSV/JSON) giving WMF staff on-demand access to aggregated data across all editing projects on the P&E Dashboard.
- An overhauled system-wide metrics layer new metrics, updated calculations, and a redesigned public-facing statistics page to make the impact of organized editing visible to the whole community
Both deliverables are grounded in the existing Ruby on Rails codebase and will follow the project's established conventions for data aggregation, API design, and React-based frontend components.
**2. Motivation & Context**
**2.1 The Problem**
The P&E Dashboard already collects granular data: article edits, bytes added, new editors, article quality scores via ORES, wiki coverage, and more. However, three gaps limit its usefulness for institutional stakeholders:
- WMF staff point person @FRomeo_WMF must manually compile system-wide data on request- a slow, error-prone process that cannot scale as the number of programs grows.
- The existing /stats page exposes only a narrow slice of available metrics and has not been substantially updated to reflect newer data models.
- There is no API surface for programmatic consumption of aggregate statistics, making integration with WMF analytics pipelines impossible without a custom database query.
**2.2 Why This Matters**
The P&E Dashboard is the primary tool that Wikimedians worldwide use to organize and document their impact. Robust, accessible system-wide statistics serve multiple audiences: WMF staff making grant decisions, program organizers demonstrating community value, researchers studying organized editing, and the general public exploring the Wikimedia ecosystem. Automating data access directly removes a recurring bottleneck for WMF operations.
**3. Technical Approach**
**3.1 Codebase Orientation**
WikiEduDashboard is a Ruby on Rails application with a React/JSX frontend, a MySQL/MariaDB database, and Sidekiq for background jobs. Data about courses, revisions, and article quality is regularly fetched from Wikimedia APIs and stored in local tables. The existing app/controllers/analytics_controller.rb and related models are the natural anchoring point for new data-export features.
**3.2 System-Wide Data Download Endpoint**
A new Rails controller - app/controllers/staff_downloads_controller.rb will expose authenticated endpoints under /staff/downloads. Access will be gated by an admin/super admin role check consistent with the existing Role model. The endpoint will support:
- Format selection: ?format=csv and ?format=json query params, handled by Rails respond_to.
- Scope filtering: by date range, wiki, program type (course, edit-a-thon, generic), and campaign.
- Async generation for large datasets: a Sidekiq background job generates the file, stores it temporarily and delivers a download link preventing request timeouts.
- Audit logging: every download request will be recorded with staff user ID, timestamp, and filter parameters.
Exported fields will be defined in a dedicated presenter class (app/presenters/system_data_presenter.rb), making the shape of exports easy to review and extend. Initial field set (negotiated with mentors and @FRomero_WMF):
- Program metadata: id, title, type, campaign, institution, home wiki, start/end dates, language.
- Participation: total editors, new editors (registered during course), returning editors.
- Content impact: articles edited, articles created, bytes added, references added.
- Quality signals: average article assessment before/after (via ORES wp10 scores), total articles improved.
- Coverage: list of wikis edited across.
**3.3 Overhauled System-Wide Metrics**
The existing SpecialStats model and /stats view will be refactored into a dedicated SystemStats service object (app/services/system_stats.rb) responsible for computing and caching aggregated metrics. Caching will use Rails.cache with a configurable TTL (default 24h), refreshed by a nightly Sidekiq job.
New and updated metrics to be added (full list subject to mentor review):
- Active programs: currently tracked vs. all-time totals, broken down by type and wiki.
- Editor retention: proportion of editors active in more than one program.
- Geographic/linguistic spread: number of distinct wikis and languages covered.
- Content quality improvement: aggregate delta in article assessment scores.
- References added: a new metric leveraging existing revision data.
- Historical trend data: monthly aggregates for plotting over time.
**3.4 Frontend Updates**
The public /stats page will be redesigned as a React component tree, consistent with other data-heavy pages in the codebase. It will feature:
- A responsive summary card row (total programs, total editors, total articles improved, total wikis).
- Time-series charts (using the existing Recharts or Chart.js integration already present in the codebase).
- Filterable metric breakdowns (by wiki, program type, and date range).
- A JSON API endpoint (/api/v1/stats) to expose the same data for third-party consumers.
**3.5 Testing Strategy**
Every new Ruby class will have RSpec unit tests, and new controller endpoints will have request specs. React components will be covered by Jest/RTL tests. I will target ≥90% line coverage on all new code. CI must remain green (rake spec + npm test) throughout.
**4. Project Timeline**
Total: 350 hours over approximately 14 weeks. The project is structured in four phases with a buffer week for review and unexpected complexity.
| Phase / Week | Hours | Deliverables |
| `Community Bonding(Weeks 1–2 (May 1 - May 24)` | 30 hrs | Deep dive into codebase: trace existing stats models, course/campaign data pipeline,Get up to speed with mentors and codebase. and role/permissions system.Trace existing stats models, Sync with mentors and FRomero_WMF to finalize export field requirements.the course/campaign data pipeline, Set up dev environment,and the role/permissions system. complete any outstanding microtasks,Sync with mentors and FRomeo_WMF to finalize the export field requirements and agree on the full metrics list. and writProduce a detailedwritten implementation spec for reviewor mentor sign-off before coding begins. |
| `Phase 1(Weeks 3–6)`May 25 - Jun 20)` | 90 hrs | Build the staff ddata-download infrastructurefoundation: StaffDownloadsController, SystemDataPresenter with admin role-gating, role-gating middlewarenew route, async Sidekiq jobSystemDataPresenter, Active Storage integrCSV and JSON serialization, audit log model and migrationasync Sidekiq job, CSV/JSON serializationActive Storage file handling, and full RSpec request/unit test suiteaudit log model + migration. Submit PR 1Full RSpec request and unit test suite. Submit PR 1 for review |
| `Phase 2(Weeks 7–10)`Jun 21 - Jul 9)` | 100 hrs | Refactor SpecialStats into SystemStats service. Implement new metrics, caching layer, and nightly refresh job. Build /api/v1/stats JSON endpoint. Redesign /stats page as React component with summary cards, time-series charts, and filter controls. RSpec + Jest tests. Submit PR . Midterm evaluation.
| `Phase 3(Weeks 11–13)`Jul 11 – Aug 16)` | 90 hrs | Stakeholder feedback pass: address WMF/mentor review comments. Implement additional filter options and any newly requested metrics. Improve download UI (progress indicator, history of past downloads for staff). Performance profiling and query optimization for large datasets. Documentation: API docs and admin guide updates. |
| `Buffer & Polish(Week 14)`Aug 17 – 24)` | 40 hrs | Bug fixes, accessibility review of new UI, code cleanup per Rubocop/ESLint. Final PR reviews and merge. Write project summary blog post for Wikimedia Foundation channels. Write project summary for documentation purposes |
Midterm evaluation target (end of Phase 2):Jul 6–10): the staff download endpoint is fully functional and merged; (PR 1); the SystemStats service and new metrics backend are complete and tested; the redesigned /stats React page is open for review (PR 2). The post-midterm period (Phase 3 + Final Polish) is dedicated to stakeholder feedback, performance hardening, the new metrics backend is complete and tested;documentation, the redesigned /stats page is in review.and a clean final submission by August 24
**5. About Me**
I am a Masters student studying Computer Science(AI/ML) in Obuda University, I have experience working as a full stack developer for 3.5 years and 3 years contributing in open source
I have 3 years experience writing code in Ruby and React.
**5.1 Engagement with WikiEduDashboard**
I set up the full WikiEduDashboard development environment locally early in my application process, working through the project's setup documentation and resolving environment-specific issues along the way. That hands-on exploration gave me a solid map of the codebase — how courses, campaigns, revisions, and users relate to each other, how background jobs are structured with Sidekiq, and how the React frontend consumes Rails API endpoints.
I have submitted and merged the following contributions as part of my application preparation:
**Issue #6557** — Admin CSV export for all public courses and instructors. I added a new admin-only ReportsController action, a new route, and extended ReportCsvWorker to generate the file asynchronously, preloading associations to avoid N+1 queries and using find_each for batch processing. This PR directly mirrors the core technical work planned for this GSoC project.
**Issue #6646** — Live preview for the Site Notice admin setting. I replaced a single-line text input with an auto-expanding TextAreaInput and built a new SiteNoticePreview React component with dynamic state sync via useEffect, giving me direct experience with the project's React component and state management conventions.
**6. Deliverables Summary**
- Authenticated staff data-download endpoint with CSV and JSON support, async generation, audit logging, and scoped filtering.
- SystemStats service object with expanded metrics set, 24-hour cache, and nightly refresh background job.
- /api/v1/stats public JSON endpoint for third-party analytics consumers.
- Redesigned /stats React page with summary cards, time-series charts, and filter controls.
- Comprehensive RSpec and Jest test suites (≥80% coverage on new code).
- Updated API and admin documentation reflecting all new functionality.
7. Risks & Mitigations
|Risk | Mitigation
| Export field requirements unclear | Finalize spec with FRomero_WMF during community bonding before writing any code.
| Large dataset query performance | Profile early with realistic data volumes; add database indexes and paginate exports. |
| Async job complexity | Start with synchronous CSV generation; move to async only once synchronous path is fully tested. |
| Scope creep on metrics | Prioritize a small, well-defined set of high-value metrics; defer nice-to-haves to a follow-on PR. |
| Availability conflicts | I wrap up my semester on May 24th and will have no conflict schedule till August