Hi @RitikaPahwa4444 thank you for your proposal. Please note that you must have at least 2 mentors for a project; be sure to include their Phab usernames. Also you must include microtasks, ideally linked to this task.

We will not be able to accept your proposal without these. Thanks!

Hi @LGoto, thank you for checking the proposal. I have reached out to the mentors to get their Phabricator handles and had created this ticket to share it with them. Is there a way to convert this proposal into draft until I get the details?

@RitikaPahwa4444 There is no draft option but now that we know you are still working on this, it's fine. Please keep in mind the deadline of 26 January 2026 to complete your proposal.

Please note that you must have at least 2 mentors for a project; be sure to include their Phab usernames. Also you must include microtasks, ideally linked to this task.

Hi @LGoto, we've added these details now to the description.

Hi @RitikaPahwa4444 Please add the microtasks for this project.

Also it would be helpful if you could provide more details about the impact, for example: why does it matter? who does it help?

Thanks!

@LGoto we have defined how to choose a microtask here: https://github.com/commons-app/commons-app-documentation/blob/master/android/gsoc.md. It has been added to the description. Is there anything else that you would like us to add?

I will define the impact in terms of the parameters you've defined.

@RitikaPahwa4444 A microtask should be an easy, self-contained task on Phabricator that prospective contributors can work on to get familiar with the project and technologies. It's a bit confusing to go to https://github.com/commons-app/commons-app-documentation/blob/master/android/gsoc.md and not see an obvious list of tasks. Also the "Tasks" section links to one declined task and one discussion threat which does not seem to be an actual task. Could you please select some sample tasks to help contributors get started?

@LGoto we've made our microtask selection flexible and this is how we've been doing for all the previous GSoC editions. My personal observation with selected microtasks is that contributors end up fighting for the tasks. Double effort doesn't help us and do not want anyone's effort to go in vain. Moreover, we don't want to set wrong expectations in terms of selections. We can link good first issues to get newcomers started, but that might not guarantee a selection. They might think "we did the given task but still did not get selected". Slightly complex tasks makes it challenging for the newcomers.

If this is a specific requirement that Wikimedia will go with this year, we'll plan on some tasks and reconsider how we select candidates.

Also the "Tasks" section links to one declined task and one discussion threat which does not seem to be an actual task.

Thank you, I've updated the task section to remove the declined task. What's the other threat that you're referring to? I'm not sure if any other concerns were discussed for the other idea.

I'll add the Phabricator links of these ideas too along with the GitHub issues if that's what you're talking about :)

My apologies for the typo, I meant "thread" not "threat" - for example: https://github.com/commons-app/apps-android-commons/issues/1192

Adding Phabricator links for the issues would be great, thanks!

After discussion with the org admins and mentors, we’re pleased to share that early contributions are more than welcome for this project. There’s no need to wait until March 16 to start working on code or submitting your microtask patches; feel free to dive in whenever you’re ready.

We look forward to seeing your ideas and contributions. Happy coding!

I’m very interested in contributing to the Modularization + Jetpack Compose project for Android Commons. I’ve already set up the project locally and explored the beta app to understand the current workflows.
@Neeldoshii @LGoto

Hi @Neeldoshii @Kaartic,

I’m Atharva, a B.Tech 2nd-year student with experience in Android (Kotlin) and frontend development. I’ve set up the Android Commons app locally and explored the current architecture and beta workflows.

I’m particularly interested in the Modularization + Jetpack Compose project and would love to start contributing early.

As a first step, I’m reviewing existing UI screens to identify candidates for Compose migration and studying current module boundaries to understand modularization challenges.

Please let me know if there’s a specific area (UI screen, module refactor, or issue) you’d recommend as a good first contribution.

Thanks!

Hi all,

Thank you for your interest in contributing! To get started, please review the microtasks section in the ticket description to learn how to pick an issue. We collaborate mostly on GitHub, so if you find an issue you'd like to tackle, simply drop a comment asking to be assigned :)

Thanks!

I'm Shoaib, a native Android developer with 3 years of professional experience in Kotlin and Jetpack Compose. My background covers the full Android evolution — Java+XML → Kotlin+XML → Kotlin+Compose — and for the past 1.5 years I've been delivering production projects exclusively in Compose with Material 3. I'm very interested in contributing to this GSoC 2026 project. I've already started exploring the commons-app codebase and submitted PR #6742. I'd love to contribute to the Modularization + Compose migration work and would appreciate any guidance on where to start.

Hi @Neeldoshii @Kaartic ,

I've been exploring the codebase and I'm very interested in the Jetpack Compose Migration project for GSoC 2026. I have 6.5 years of Android/Kotlin experience and I'm already familiar with Compose. Could you help me understand the current migration status and which screens are prioritised? I'd love to start contributing in this area also I've already started exploring the commons-app codebase.