commons-app
Wikimedia Hackathon 2026
So, it's that time of the year again! The Wikimedia Hackathon 2026 will be held in Milan from 1-3 May 2026, and travel scholarship applications are open until 28 Nov this year.
I'm planning to apply for one to attend. Would be great if a few of us could meet up and work together. :)
If I'm approved, I think I'd like to work on creating a proof-of-concept or prototype for a multiplatform Commons app. I've been thinking of it ever since it was suggested by @nicolas-raoul here, and I feel like a potential for convergence might address some of WMF's concerns re: maintainability and consistency of a separate iOS app.
Going further down that route, here are some of my thoughts of how we'd go about this:
- Design: WMF mobile app staff often attend these events, we could collaborate with them on coming up with a UI/UX and design that suits the brand.
- Tech stack: I'm leaning towards React Native personally, partly because that appears to be the industry standard for multiplatform mobile apps at the moment, and partly because I myself am keen on upskilling in that area. Totally open to suggestions though - other options include Kotlin Multiplatform.
- Scope: Needs to be super small for a hackathon, I'm thinking just a very basic login and upload flow. If we have time, Nearby would be nice.
Anyway, all of this is completely up for discussion! Let me know what you all think, and also if you're planning to apply. :)
P.S.: If we do this, I think we need at least one person with an iPhone and a Mac to compile and test. I'm a Windows and Android person myself (heh), and AFAIK we can use Expo to develop on Windows, but to publish (even on TestFlight) I think we need a Mac.
Unfortunately, I might not be able to attend in-person, but always up for help and discussion virtually 🙌🏻
Design: WMF mobile app staff often attend these events, we could collaborate with them on coming up with a UI/UX and design that suits the brand.
Good time for https://github.com/commons-app/apps-android-commons/issues/6392 I guess :)
Tech stack: I'm leaning towards React Native personally, partly because that appears to be the industry standard for multiplatform mobile apps at the moment, and partly because I myself am keen on upskilling in that area. Totally open to suggestions though - other options include Kotlin Multiplatform.
If it's a complete re-write, react native sounds good. Just thinking: given that our codebase is in Kotlin already, it might be easy to re-use a good amount of code with ease and ship quickly using KMP. I see we had a flutter app already, so extending that might also be an option.
Good time for https://github.com/commons-app/apps-android-commons/issues/6392 I guess :)
Great idea! :) Definitely saves time to incorporate the Codex right from the start. I reckon we could collab with designers to create a Figma design with their components, and use that as the base for the prototype.
If it's a complete re-write, react native sounds good. Just thinking: given that our codebase is in Kotlin already, it might be easy to re-use a good amount of code with ease and ship quickly using KMP. I see we had a flutter app already, so extending that might also be an option.
I don't know if extending the Flutter app is a good idea - we made that as a demo for a pitch a long time ago (in 2019-ish?) and haven't worked on it since. It feels like we might end up spending more time refactoring legacy code. It could be handy to use as a reference though, and some of its code could potentially be reused if we go the Flutter route.
So I think our options are:
- React Native: The biggest ecosystem currently, transferable and in-demand skill, lots of well-known apps are made in it, can use Expo to simplify builds and deployment (not sure how far the free version of Expo will take us, though).
- Flutter: Second-biggest ecosystem, popular among devs, Google support
- KMP: Much smaller ecosystem than the other two. But everyone here is already familiar with it and some code can be reused.
Hey all, just a reminder that the travel scholarship applications close on 28 Nov (next Friday). :)
Pinging anyone who might be interested @sonalyadav1 @Kota-Jagadeesh @madhurgupta10 @kanahia1
+1 for KMP. React native can also be a nice option as the framework is mature, and KMP is new. But JetBrains and Google are working actively to extend existing Android libraries and make them KMP-ready. Also, it would save us much time and would be easy to migrate our codebase to KMP instead of writing everything from scratch.
My experience with React-Native is not that good. I got a chance to work on react-native apps in the past few months, and I faced a lot of issues with react-native libraries. Even on the latest versions, some libraries can easily break our app. However, the community is large, so fixes are deployed much faster. Apart from that, I saw a practice, while working with libraries, that we usually patch the library fix if the solution is yet to be found or not yet released. And maintaining patches in our codebase is quite difficult unless they are very small fixes.
So if I have to choose between react-native and KMP, I'd choose KMP if the target platforms are Android and iOS. I'd only go with react-native if we are developing for web along with Android and iOS, because I think that React is best for web apps.
I think I should only select option 2 here. Could you please confirm, @misaochan?
Also, what would be accurate here? I've been contributing to Commons since 2024, but I don't know if that counts under Wikimedia projects because it was mentioned under the Wikipedia projects above.
Thank you :)
@rohit9625 Those options are indeed confusing. I believe the distinction is that the first one is technical, and the second one is non-technical. I selected both personally, as I have contributed technically (code) and non technically (images to Commons).
Commons is a Wikimedia project and I'm not sure why it was listed as an example for Wikipedia. In your case, definitely select the first option, and additionally select the second if you have uploaded images before.
2024 is fine to use IMO.
Please bear in mind that I'm not in the scholarship committee so this is just my interpretation. :)
thanks for the ping @RitikaPahwa4444 i will apply for the scholarship 🤞
i have a personal liking for KMP so I would lean towards it and I think cause we are already using a lot of kotlin it would be easier.
@shankarpriyank Awesome to hear that! :)
I'm good with using KMP if the majority prefers it.
Great discussion. All the best with the applications! @RitikaPahwa4444 @misaochan
While we look towards the future, I do want to raise a point from a product perspective regarding our current stability. We have quite a few open bugs and are facing reports of app crashes from users.
Before we commit fully to new prototypes, what is our strategy for tackling these existing issues? We need a robust plan to ensure the current app remains stable. Should we perhaps open a separate thread to discuss a "stability roadmap" or a dedicated bug-fixing sprint?
@gopalakrishnaa I expressed my views on some other issue regarding this.
Before we commit fully to new prototypes, what is our strategy for tackling these existing issues?
Hackathons are meant for building prototypes, so it's completely fine if the members want to build some :)
Should we perhaps open a separate thread to discuss a "stability roadmap" or a dedicated bug-fixing sprint?
Not aligned with having the concept of sprints - we are not working in a corporate environment and we need to keep things open-ended as everyone is a volunteer here, and many of them are new contributors. GSoC/Outreachy have indeed helped us a lot to drive the project, but even for paid projects we can't keep bug fixes for the entire 3-month duration.
For any bugs impacting a large number of users, I report it against the release version and sometimes fix it myself. Or add high priority label and the community helps to fix them. Every open source project has bug reports, and not all need to be prioritised :) Please feel free to open a new issue for discussing the priorities along with the data points. Thanks!
@RitikaPahwa4444 Thanks for the perspective! :) I think there was a slight misunderstanding regarding my use of the term "sprint." :)
I was not suggesting a corporate-style crunch with strict deadlines. I was referring to the concept of a community-focused event—similar to the "Edit-athons" or "Bug Smash" campaigns common in the Wikimedia world, or even Hacktoberfest, which many of us already participate in. These are open-ended, volunteer-friendly events where we rally the community to focus on a specific theme (like stability) rather than new features for a short period.
My concern is that without a "Stability Roadmap" or a focused cleanup effort, we keep piling new prototypes on top of unresolved issues. For example:
- Feature Debt: We have good ideas like #6408 (Speedy Deletion) that are effectively blocked (Even though community gave positive feedback) because we haven't resolved pre-requisite issues like #2852 (frivolous nominations).
- Critical Bugs: We have persistent issues like #6351 (Nearby upload reliability—currently tagged for Hacktoberfest) and #6446 (Login errors) that directly impact the core user experience.
If we commit to new prototypes in a Hackathon without addressing these, we risk building on a shaky foundation. A "Bug Squash" hackathon could be a fun way to onboard new contributors to the core codebase, rather than just building isolated features. :)
My experience with in-person hackathons has been that people tend to gravitate towards projects that sound fun and interesting. Unfortunately bug fixing is generally not something that attracts a lot of attention, so I think we would end up with a smaller group if we did that. It's also an opportunity to collaborate with WMF staff in areas that we are severely lacking, e.g. design (since most of us are developers).
But as I mentioned earlier, I'm flexible with what exactly we do at the hackathon, so if the general consensus is that we want to be fixing bugs, I can work with that. :)
Hacktoberfest is indeed a very good match for bug fixing though, as AFAIK they tend to encourage participants to work on small and modular issues. Do you know if we've participated in this recently, @RitikaPahwa4444 ?
If we commit to new prototypes in a Hackathon without addressing these, we risk building on a shaky foundation.
Stability is supposed to be an ongoing concern rather than a 2-day hackathon focus. As @misaochan said, hackathons are supposed to be fun, and it's completely fine to build a new functionality or a new prototype to understand if a re-write gives more benefits over the current code. If we stop experimenting and keep waiting for the right time, we risk losing out on discovering innovative ways.
A "Bug Squash" hackathon could be a fun way to onboard new contributors to the core codebase, rather than just building isolated features. :)
We expect contributors to fix 5 bugs before they start picking up new features. Kindly read our volunteer guidelines for the details.
Do you know if we've participated in this recently, @RitikaPahwa4444 ?
Yes @misaochan, we did participate in Hacktoberfest this year 🙌🏻
@RitikaPahwa4444 That's awesome!
I also forgot to mention that the map of nearby places that need photos was initially conceptualized and created at a hackathon! It eventually became our most popular feature. :) Of course, that feature has evolved and grown over the years since then, but we made the first prototype as an experiment during the 2016 hackathon, to see if people liked the idea.
Hackathons are incredible for getting eyes on something new, or getting feedback from the community IMO.
Edit: Oops, tapped "close" by mistake.