Profile
Name: Shashwat Kedia
Location: Chennai, Tamil Nadu, India
Education: B. Tech, Indian Institute of Technology Madras (Expected graduation year: 2027)
GitHub: ShashwatKedia
LinkedIn: Shashwat Kedia
Other Communication Modes: Zulip, Slack, Discord
Typical working hours during GSoC: 9 am - 10 pm (IST) UTC+5:30
Synopsis
The Commons app is an open-source Android app that allows anyone to upload pictures to Wikimedia Commons (the image repository used by Wikipedia, Wikinews and other projects).
Commons Android app repository: GitHub
Project
This project aims to fix upload queue management and improve the 'Neaby' of the Commons app.
GitHub issue: Fix upload queue management
Mentors
@Nicolas_Raoul @RitikaPahwa4444
Have you contacted the mentors already?
Yes.
Deliverables
I have broken the proposal into 3 major tasks:
- Improving Upload Queue Management (#5589), Implementing best possible UI for pending uploads(#5587), and Fixing erratic pause and resume button (#5524)
- Fixing different cases and problems related to failing uploads (#5603, #5284, #5283, #5280)
- Improving the 'Nearby' feature: Loading pins as the user moves the screen, caching pins, and removing the "search this area" button (#5664)
Implementation Strategy
Task 1
(i) Improving Upload Queue Flow (#5589, #5524): Currently, the uploads which have not started have either a Queued tag or a non-started progress bar animation (which is sometimes allocated randomly). I propose to remove the non-started progress bar animation for uploads yet to be started and instead give them all the tag Queued (N), where N is the position of that image in the upload queue. This will help the user know which image will get uploaded after which one, as the N will be updated after every successful image upload.
Also, I propose to address an extra task, #5524, as I thought that it's imperative to fix the pause/resume button behaviours to improve the upload management task as a whole. It would be easier for one already working on the upload queue management to fix the pause/resume button behaviours simultaneously rather than working on it later.
Proposed upload queue flowchart:
(ii) Improving Upload Queue UI/UX (#5587): There can be two possibilities for the best UI/UX of pending uploads.
the first approach is that we keep the pending uploads in the contributions fragment (which is what the app currently does). There are some problems with this approach:
(a) Currently, only 2-3 images are visible at a time and if multiple images are uploaded then user has to scroll a lot to view the status of the images.
(b) If the topmost upload fails/is paused, but the next images get uploaded successfully, then the uploaded images go to the top of the screen and the failed/paused image gets hidden as it moves down
The second possibility is that we can create a separate PendingUploads screen, that’s completely focused on managing the in-progress uploads of a user and providing them with more flexibility to manage them seamlessly. I'm also thinking of adding a CTA when the new PendingUploads screen has no pending uploads, something along the lines of these designs, where the text can be "No pending uploads. Upload images now to see them here!" Though, thinking about the best possible UI/UX for the app is a part of GSoC itself, I've made some UI mockups which can improvised upon after taking feedback from my fellow contributors on GitHub :)
Task 2
(i) Uploads never get stuck(#5603): Upload hundreds of upload-worthy images to reproduce and debug the issue and find potential solutions to it.
(ii) Prevent retries for genuinely failed uploads(#5284): As discussed in the issue and a draft PR related, prepare a list of cases of 'genuine' reasons for failure. Add logic to prevent retry of upload if it failed for 'genuine' reasons and show the user the reason for failure.
(iii) Enqueue failed uploads(#5283): As discussed in the issue, this happens potentially because of a UI error, as the progress bar seems to move for only 1 image, even though two of them have it.
(iv) Never show successfully uploaded images as "Failed"(#5280): Intensively debug to reproduce the issue and fix the problem associated with it.
Task 3
Load pins automatically, cache them and remove the "search this area" button (#5664): Using the hints given in the issue description and comments:
(i) Write the logic to automatically load pins as the user moves through the map, like Wikishootme does
(ii) Write cases of cache invalidation to remove old cached pins
(iii) Safely remove the existence of the "Search this area" button
Timeline
| Timeframe | Classification | Task Description |
|---|---|---|
| 1 May - 26 May | Community Bonding Period | Connect with the mentors and learn more about the community, familiarise with the app structure, and understand more about the upload queue by uploading hundreds of upload-worthy pictures. Discuss the best UI/UX for the pending upload queue with the mentors and fellow contributors. |
| Partial Unavailability | Partially unavailable from 5 May to 16 May due to university end-semester examinations | |
| TASK 1: Issue #5589, #5524 | ||
| 27 May - 31 May | Deliverable | Report key findings and finalise implementation strategy |
| Subtask 1 | Intensively test the upload queue under different scenarios and network parameters and record observations | |
| Subtask 2 | Analyse the scenarios and prepare a report on the observations recorded | |
| Subtask 3 | Discuss and finalise the implementation strategy for improving the upload queue | |
| 1 June - 10 June | Deliverable | Fix upload queue management and pause/resume behaviour |
| Subtask 1 | Implement the finalised strategy | |
| Subtask 2 | Fix pause and resume behaviour | |
| Subtask 3 | Intensively test the application for any new bugs | |
| 11 June - 16 June | Deliverable | Implement the finalised UI for pending uploads |
| Subtask 1 | Implement the finalised UI for 'Pending uploads' | |
| Subtask 2 | Intensively test the application for any new bugs | |
| 17 June - 21 June | Deliverable | Unit Tests |
| Subtask 1 | Write/Modify unit tests for the implemented changes | |
| Subtask 2 | Intensive manual testing for all possible cases and network issues | |
| 22 June - 25 June | Deliverable | Finalise changes for Task 1 |
| Subtask 1 | Complete any pending task(s) | |
| Subtask 2 | Implement any changes suggested by mentors | |
| Subtask 3 | Report/Blog about the project status | |
| TASK 2: Issues #5603, #5284, #5283, #5280 | ||
| 26 June - 30 June | Deliverable | Report key findings for different cases of failing uploads |
| Subtask 1 | Debug intensively to figure out possible reasons for the erratic behaviour of the upload queue while dealing with Failed images and images getting stuck | |
| Subtask 2 | Prepare a list of all genuine cases of Failed uploads | |
| Subtask 3 | Analyse the scenarios and prepare a report on the observations recorded | |
| 1 July - 7 July | Deliverable | Fix #5603 and #5283 |
| Subtask 1 | Enqueue failed uploads instead of uploading simultaneously | |
| Subtask 2 | Fix queued uploads getting stuck and implementing a more robust retry upload function | |
| Subtask 3 | Intensively test the application for any new bugs | |
| 8 July - 11 July | Evaluation | Mid-term evaluation |
| Subtask 1 | Finalise the changes | |
| Subtask 2 | Report/Blog about the key findings and accomplishments | |
| 12 July - 18 July | Deliverable | Fix #5284 and #5280 |
| Subtask 1 | Preventing retry for uploads according to the "Genuinely Failed" list. | |
| Subtask 2 | Preventing the app from showing successfully uploaded images as Failed | |
| Subtask 3 | Intensively test the application for any new bugs | |
| 19 July - 24 July | Deliverable | Unit tests |
| Subtask 1 | Write/Modify unit tests for the implemented changes | |
| Subtask 2 | Intensive manual testing for all possible cases and network issues | |
| 25 July - 28 July | Deliverable | Finalise the changes for Task 2 |
| Subtask 1 | Complete any pending task(s) | |
| Subtask 2 | Implement any changes suggested by the mentors | |
| Subtask 3 | Report/Blog about the project status | |
| TASK 3: Issue #5664 | ||
| 29 July - 13 Aug | Deliverable | Improve Nearby Feature: #5664 |
| Subtask 1 | Load pins automatically as user moves on Nearby map | |
| Subtask 2 | Cache loaded pins and write cases of cache invalidation | |
| Subtask 3 | Remove "Search this area" button | |
| 14 Aug - 19 Aug | Deliverable | Unit tests |
| Subtask 1 | Write/Modify unit tests for the implemented changes | |
| Subtask 2 | Intensive manual testing for all possible cases | |
| 20 Aug - 26 Aug | Deliverable | Finalise all the changes |
| Subtask 1 | Complete any pending task(s) | |
| Subtask 2 | Code cleanup and documentation | |
| Subtask 3 | Implement any changes suggested by mentors | |
| Subtask 4 | Final Report/Blog about key findings and accomplishments | |
Previous Contributions to Commons
I have been contributing to the Commons Android app since December 2023. You can find all my pull requests here.
Total: 14
Merged: 12
Open: 2
Pull Requests
1. Successfully enhanced the flow of UploadMediaDetails by calculating all the image qualities in the background and showing any problems ASAP, as oppposed to the earlier method of making the user wait for every image by calculating the quality (individually) only on NEXT button click (which also wasted user time as they would type the caption and description of the image, only to be told later that the image is already on Commons, or some other problem exists with the image):
| S. No. | Issue No. | Issue Description | PR No. | Tasks Performed | Status |
|---|---|---|---|---|---|
| 1. | #4704 | Remove Please Wait and do image quality verification task in the background | #5570 | Calculated and stored the qualities of all the images in the background and successfully displayed dialogs ASAP. Rigorously tested for different cases and types of images and wrote code to accommodate all scenarios | Merged |
| 2. | #5511, #5286 | Problems with UploadMediaDetails flow and UX | #5527 | Optimised the flow and kept the location comparer & No Location dialog from popping up multiple times | Merged |
2. Standardised the location-related flow of the app. Facilitated the successful switch to OSMDroid by resolving crucial logical errors during the switch, which caused the Map fragments not to behave normally and intensively tested for different scenarios:
Please Note: PR #5494 has been under review for the past 2 months as it's a crucial PR ;)
| S. No. | Issue No. | Issue Description | PR No. | Tasks Performed | Status |
|---|---|---|---|---|---|
| 1. | #5413 | App crashed when opening Nearby tab when app does not have location permission | #5418 | Assigned mapCenter to lastKnownLocation instead of it being null, when location permission was denied. It was a crucial PR, as this particular bug was causing a lot of problems in testing the Nearby fragment | Merged |
| 2. | #5256, #5461, #5490 | Standardise the location-related flow of the app and remove redundant code of location-based features. Nearby not working as intended. Explore tab crashing and not working as intended after switching to OSMDroid | #5494 | Changed the location flow of the fragments which require location-related services, to one standard flow. Removed most of the redundant code by using and updating the LocationPermissionsHelper wherever possible. The switch to OSMDroid brought about issues related to the normal behaviours of Nearby and Explore tabs, especially when the location permission was denied. The PR resolved these issues by enhancing the flow and intensively testing for different scenarios and results | Open |
3. Added a compass in the neaby home banner, which shows direction to the nearest place and highlights the nearest place on clicking the banner. Also enhanced the banner to update direction and distance from the nearest place as the user moves:
| S. No. | Issue No. | Issue Description | PR No. | Tasks Performed | Status |
|---|---|---|---|---|---|
| 1. | #2239 | Request to add compass feature in home nearby banner | #5433 | Computed the bearing between the 2 locations and rotated the compass in direction of the bearing. Works even when phone is held vertically :) | Merged |
| 2. | #5445 | Request to highlight nearest place on clicking the banner | #5453 | Changed marker colour of nearest place and also highlighted bottom sheet details. Additionally, solved the bug of the nearby home banner disappearing after clicking it once | Merged |
| 3. | #5444, #5455 | Updating distance as user moves Banner compass does not change direction after walking past it. | #5459 | Updated nearby banner whenever user moves slightly, which resets the distance as well as direction of the nearest location. | Merged |
| 4. | #5483 | Compass flickering as user moves | #5486 | Removed initial direction set of compass | Merged |
4. Minor bug fixes and UI Improvements:
| S. No. | Issue No. | Issue Description | PR No. | Tasks Performed | Status |
|---|---|---|---|---|---|
| 1. | #4664 | Migrate from Kotlin extensions and Butterknife | #5506 | Moved the SettingsActivity from Butterknife to ViewBinding | Merged |
| 2. | #4513 | Scrollbar was not visible until user actually tried to scroll it | #5420 | Added property fadeScrollbars and set it to false. Also added background colour and width to the scrollbar , without which it doesn’t show up on some devices | Merged |
| 3. | #2307 | Making achievements activity more visible | #5442 | Making achievements activity more visible | Merged |
| 4. | #5194 | Some icons are barely visible in dark mode | #5410 | Changed colour-tint of required icons to primaryLightColour | Merged |
| 5. | #5411 | Incorrect orientation of the arrow in media details card | #5412 | Rotated image button by 180 degrees and renamed the arrow image file | Merged |
Pull Request Review
| S. No. | Issue No. | Issue Description | PR No. | Tasks Performed |
|---|---|---|---|---|
| 1. | #5474 | App crash on switch from Light/Dark mode in the LocationPickerActivity. | #5500 | Found a crucial case of the app crashing due to the changes and the reason for the crash. Suggested some code formatting improvements as the code style was a bit off. |
Participation
- I plan to create an Excel sheet which will be updated everyday with the work done on that particular day. It's link will be shared with the mentors to monitor my progress.
- I will communicate with mentors on Zulip and GitHub based on the nature of the discussion.
- I plan to take feedback from the community on GitHub for any specific changes required or any preferred UI/UX, as it's essential to incorporate changes suggested by the fellow developers :)
About me
I am Shashwat Kedia, a first-year undergraduate student at the Indian Institute of Technology, Madras, currently pursuing my B. Tech in Biological Engineering. I have been a software geek since my high school days and have a knack for problem-solving.
How did you hear about this program?
I got to know about this program from a senior at my university, who also happens to be a two time GSoC alumnus.
We advise all candidates eligible for Google Summer of Code and Outreachy to apply for both programs. Are you planning to apply to both programs and, if so, with what organization(s)?
I am eligible to apply for Google Summer of Code only and am applying only to the Wikimedia Foundation.
Past Experience
I have worked as an Android developer intern (3 months), wherein I worked in a team of 3 members to develop an application which collects and stores data of potential Parkinson's patients. That data is analysed and used to predict and diagnose the patient.
Apart from this, my personal projects include:
Be Alert: Women Safety App: Developed a unique Android app, which triggers the SOS Alert can be started by just shaking the device hard once, even if the app is closed. When the emergency is triggered, the app sends a message to selected contacts with your current location and also captures images from the back and front camera while recording audio of about 45 seconds. Then the app will dial up a selected contact and put the call on speaker automatically (currently, the speaker feature is supported only by Android devices running Android version 8.0 and below due to restrictions posed by Android)
Test Your Brain: Bull & Cow: Digitised the classic game of 'Bulls and Cows' into an Android app with a clean and attractive UI. Has different modes such as single-player, multiplayer and online room.
My personal homepage: https://shashwatkedia.github.io/PersonalHomepage/
Volunteer Experience
- Coordinator, Institute WebOps and MobOps Team, IIT Madras
- Deputy Coordinator, AI Club, IIT Madras
- Deputy Coordinator, WebOps and Blockchain Club, IIT Madras
Relevant Skills
- Experience in Android development with Java, Kotlin, XML
- Understanding of Git and GitHub
- Unit tests and instrumented testing
- Proficiency in using SQL and Room Database
- Understanding of Retrofit, RxJava, Jetpack Compose
- Knowledge of Wikimedia APIs
Motivation for applying
I have always used Wikipedia for all my school projects, as we didn't have any ChatGPT at that time ;) and it was the most reliable source for all information. The images in the articles were of great quality and relevance. Since the Commons Android app is used to upload images which might be used in articles, it's my chance to give back to the Wikimedia Foundation. I am fortunate enough to have skills which can be used to help build and maintain the Commons Android app, so I would like to utilise them to the fullest through this program. While contributing to the app, I learnt a lot of skills and stuff which can never be taught in any Android development course and thus want to apply these for the betterment of the app itself.
Availability
Are you eligible for Google Summer of Code?
Yes.
Do you plan to submit any other proposal apart from this one?
No, I plan to submit only this proposal.
Do you have any other plans during the period of GSoC?
No, I do not have any other plans during the contribution period. Google Summer of Code is my topmost priority this summer.
How many hours per week can you dedicate to this?
Since a major portion of the contribution period would be covered under my summer break (up to July 29), I can dedicate approximately 35-40 hours per week. I can even increase the number of hours if and when required for the tasks to be completed on time.
Have you been accepted to GSoC before?
No. I am applying to the GSoC program for the first time.
Why I am the ideal candidate
- I have been an active contributor to the Commons repository since December 2023 and have worked in almost all parts of the app, ranging all the way from UploadMediaDetails & Achievements to Nearby & Explore fragments. Thus, I am familiar with almost the whole of the code base, the code style and other norms followed by the app and the community.
- I have solved issues which required intensive manual testing of the app in different cases and scenarios and optimising logic for all those scenarios, which is similar to the target of this GSoC, as it will be required to intensively test and optimise logic for different scenarios of the upload queue with it's new UI as well as the improved Nearby map.
- I have patiently and efficiently implemented all minor changes and tweaks, as instructed by the maintainers during the review of a PR, sometimes over a period of 2 months (like in #5494 ).
- Many times, I have independently found solutions and ideal flows when the maintainers couldn't reply/take a look due to a time crunch ( like in #5570 )
- I understand the vision of the founders and maintainers of the Commons Android app, which is to expand the reach of free Wikipedia, especially to the most under-represented regions like Africa, by making it more fun and convenient to upload pictures. I align with the same thoughts and want to help achieve this goal by contributing to this project.
- I wanted to participate in the Wikimedia Hackathon 2024 but couldn't apply, as its dates clashed with my university end-semester examinations. Thus, GSoC is my only chance this year to work intensively on this project.
Post-GSoC Involvement
My journey with the Commons Android app has been truly amazing, and I have learnt a lot while contributing. I have gained such exclusive knowledge about the workings of Android, which no formal course could teach me. It's the first open-source organisation to which I am contributing and will always hold a special place in my heart. Irrespective of whether I am selected for GSoC this year, I will keep contributing to the organisation as much as I can and help it achieve greater heights. If the maintainers feel so, I can also volunteer to mentor for next year's GSoC program, and it will be an honour for me to do so.