Introduction

Montage is one of the most used photo evaluation tools for and by Wiki Loves competitions. It allows us to create campaigns to evaluate photos of each competition where the images are posted in Wikimedia Commons. Each campaign consists of 3 rounds where the jurors would qualify, rate and rank each entry throughout the campaign.
Montage has a flexible workflow that is adaptable to contests of all sizes, and is suited for evaluation of 10-1000s of images.

Montage is one of the most impactful projects made for Wiki Loves Competition, however after the last release in 2019, there have been a lot of standing issues which need to be fixed. By the end of the project, Montage will be ready for its v26.0.0 release, with a stable codebase and up-to-date interface, and an improved development workflow.

Benefits of Community

Wiki Loves Monuments is a program that happens every single year and montage plays a significant role in evaluating photos taken in the program. Thus, having a bug-free release is of utmost importance, The WLM community along with other Wiki Loves contest communities, relies on Montage to ensure that the judging process remains smooth and efficient.

A stable system directly benefits the community by improving the overall experience for both jurors and the organizers. When the tool functions reliably, jurors are no longer required to deal with technical difficulties and have to report it to developers mid evaluation. This reliability is particularly important because Wiki Loves competitions operate on strict timelines, where delays in judging can affect announcements of results and subsequent stages of the contest.

Goals

Microtasks

I have written a separate document for the write up regarding the microtasks, where I have gone through the project workflows and added my understandings for the same.
Microtask writeup

Primary Goals

New features and Enhancements

1. Comment option for rounds: As per issue #123, discussion between jurors during a round is important and could help in evaluating entries in a much better way. So a comment option can be added in each round in a campaign for the jurors to communicate about evaluation and evaluate accordingly.
2. Automate campaign request review: Currently, international coordinators have to manually approve every campaign creation request given by individual coordinators in the commons talk page for Montage, this manual process is tiresome and unreliable. Instead we can automate the whole process where the individual coordinators will fill a form in montage itself and higher coordinators will be notified with an approve and reject ( with reason ) option, and if approved, a new campaign will be created based on the given parameters.
3. Integrate with Wikimedia Commons: Currently, Montage imports entry data once during campaign creation and never sync with Commons, this can cause broken images when files are renamed (#97) or deleted (#30) and missing metadata like description (#31). This feature could implement a background sync service that periodically checks entry status against Commons and auto resolves file renames by following redirects, marks or deleted entries as unavailable and fetches updated metadata. A coordinator dashboard showing sync status and a manual “refresh entries” action will ensure jurors never encounter broken images during voting.
4. Enhance juror experience: The current evaluation flow for the jurors is forthright. There are some features which can be added to ease the juror voting:
   • Entry comparison mode: If some entries are questionable, jurors can compare them side by side and update their evaluation accordingly.
   • Grid view for entries: Instead of focused singular displaying of entries an option can be added to display images in grid view for any round, so that the jurors can evaluate much faster and easier.
   • Better workflow for skipped entries: At present the skipped entries reappear unexpectedly on a round. Those images can be separated into a section which comes once the jurors reach the end of the round. The current workflow creates a confusion when images are skipped which leads to the round complete page, even though entries are pending.
   • Favorites for jurors: Instead of manually typing juror usernames, coordinators could save a juror with an alias and can use that next time.
5. Update tests: Update the current written tests to make it more strict as mentioned in the microtask.
6. Add redis caching layer: Currently the infrastructure is dependent on the DB for every request, including repeated fetches of the same round metadata, campaign details, and image info. Adding redis as a caching layer will store frequently-accessed data ( round config, entry metadata, user sessions ) in memory, reducing db load. This is important for large campaigns with thousands of entries where the same Commons metadata is requested repeatedly.

Bug Fixes

1. Close recurring open issues: There are a bunch of open Issues on the repo, most of them are either already fixed in older commits or require a basic fix ( like validation or a feature request ). By just a simple attempt on reproducing the issues, we could easily understand whether it exists or not, this reduces future work or any other confusions.
2. Race conditions: Rapid voting causes state updates errors when the next vote is submitted before the previous one completes. This bug exists on voting pages like yes/no , ranking and in round edit.

Stretch Goals

1. Landing page: Landing page is a standard component that most of the websites have. Even though montage is more like a tool, adding a landing page would be appropriate to have. Instead of a description in the commons page, we could display contents like “About Montage”,”Features”,”No of campaigns done”, etc.
2. Clastic multi-worker: Currently, Montage runs on a single-threaded Clastic server, which limits its ability to handle concurrent requests in high-traffic periods Migrating to Gunicorn with multiple workers will allow the backend to process several requests simultaneously. This involves wrapping the Clastic application in a WSGI-compatible entry point and configuring Gunicorn with an appropriate number of workers based on Toolforge resource limits.
3. Improve documentations: Even though the current docs are mostly well written, certain parts like To-Dos , Dev.md (old file project structure) and others still require updating.

Timeline

Project duration: 350 hours

My contributions

I’ve been contributing to Montage for the past 4 months, working on both frontend and backend, other than Montage I’ve also worked on Wikimedia projects like Scribe-org. Apart from technical contributions I’m also passively active in the Wikimedia Zulip server, helping people in their contributions ( example ) and project setup.

Availability

Since I’m a college student I can dedicate around 4-5 hours on weekdays and 8-10 hours on weekends. This means that you can expect around 35-40 hours a week from me. I will be most active between 5PM-12AM on weekdays and 10AM-7PM on weekends. All times in IST.

About Me

I’m Abhinav M, a third-year Computer Science undergrad at Amrita Vishwa Vidyapeetham, Amritapuri Campus. I’m also a member at amFOSS, a student-run FOSS club at my campus. I’ve been into development at the age of 13 where I started with game dev in Unity, and that interest has continued to grow over the years into what I pursue today :). Apart from development I do write blogs in medium where I share my insights.

Projects

I’ve worked on multiple projects in my undergrad, here are some notable ones:
Priyamvada: An initiative by Central Sanskrit University and Amrita on making the world’s first sanskrit audiobook app. Currently has 3000+ users and an average rating of 4.8 on Play Store and App Store. My contributions were on building the mobile app and deployment on Play store.
Bob: A voice over AI agent for helping student developers, with a frontend built on Next js and agent made using LangChain over FastAPI backend bob can help in basically any day to day tasks and even in developing apps with its contextual knowledge graph of the current working project. Bob is voice oriented which means you don’t even have to manually type the content to explain - just speak to it.
Urbanalyze: A hackathon winning project which rates locations based on several factors in urban areas, with a frontend built on Next js and django backend. Built an analysis tool that compares locations using weather, seismic, and flood-risk data to support smarter housing decisions.

Hackathons

Along with academics and open-source contributions, I also participate in hackathons, where I work in a team building innovative solutions within the given time constraint and have won a few of them.
Here are my LinkedIn posts of the ones that I’ve won or been the finalist in:

• Zenith Hackathon
• EvoLUMIN Hackathon
• OLabs Hackathon

Why Wikimedia ?

Wikimedia projects are built around the idea of open knowledge and global collaboration. Platforms like Wikimedia Foundation support initiatives that allow people from all over the world to contribute knowledge, media and information that anyone can freely access.

Contributing to Wikimedia through tools like Montage helps improve the systems that support these large community-driven events. Unlike other open source organizations, Montage issues are actually reported by the users itself which showcases its pivotal role in the system. By improving such tools, the contribution does not only help the developers, but also the thousands of people who participate in these programs every year.