Page MenuHomePhabricator

GSoC 2023 Proposal - Commons Android app - Make upload more reliable
Closed, DeclinedPublic

Description

Profile Information

Name: Kartikay Kaushik
LinkedIn: kartikaykaushik
GitHub: kartikaykaushik14
Google Scholar: Kartikay Kaushik
Email: kartikayism@gmail.com
Resume:


Location: New York, USA
Typical working hours: 5:30 PM - 1:30 AM (PDT UTC-07:00) from 3rd June, 2023

Synopsis

About the App: The Wikimedia Commons Android app is an open-source Android app that allows anyone to upload pictures to Wikimedia Commons. Commons is utilized as the image repository for various projects, including Wikipedia, Wikisource, Wikivoyage, and Wikinews.

About the Project: The proposed project for Google Summer of Code 2023 is to make uploading images to the app more reliable. It aims to fix three upload-related bugs in the app that are affecting its functionality. Fixing these bugs will improve the app's reliability and make it easier for users to contribute high-quality images to Wikimedia Commons, which will benefit all Wikimedia projects that rely on this image repository.

Possible Mentor(s):

@Nicolas_Raoul
@Kaartic

Have you contacted your mentors already?
Yes

Deliverables

I would not be available during the community bonding period.

TimeframeStart DateEnd DateTask
Week 13-June-202311-June-2023#5196 Reproducing Issue + Investigating + Finalizing implementation strategy
Week 212-June-202318-June-2023#5196 Code changes for fixing the issue + Write and Stabilize Unit Tests
Week 319-June-202325-June-2023#5196 Deploy and Test Changes + Fix associated bugs and suggestions
Week 426-June-20232-July-2023#5196 Documentation + Merge + Phase 1 Evaluation
Week 53-July-20239-July-2023#5128 Reproducing Issue + Investigating + Finalizing implementation strategy
Week 610-July-202316-July-2023#5128 Code changes for fixing the issue + Write and Stabilize Unit Tests
Week 717-July-202323-July-2023#5128 Deploy and Test Changes + Fix associated bugs and suggestions
Week 824-July-202330-July-2023#5128 Documentation + Merge + Phase 2 Evaluation
Week 931-July-20236-August-2023#5136 Reproducing Issue + Investigating + Finalizing implementation strategy
Week 107-August-202313-August-2023#5136 Code changes for fixing the issue + Write and Stabilize Unit Tests
Week 1114-August-202320-August-2023#5136 Deploy and Test Changes + Fix associated bugs and suggestions
Week 1221-August-202328-August-2023#5136 Merge + Final Evaluation + Overall Blog Post
Implementation Strategy

Task #5196: My initial approach would be to understand the fix provided in #5190 where a similar issue is resolved in the custom picker and analyze if a fix can be prepared by building upon this approach.

Task #5128: My initial approach would be to find out the exact error, and modify the app's network parameters such as timeout or buffer sizes. An auto retry mechanism can also be added. In addition to it, I also plan to implement it as a background service where instead of relying on the user to keep the app open while the upload is in progress, we can use a background service to handle the upload.

Task #5136: My initial approach would be to understand how a single upload "unlocks" the stuck queued uploads and try if a fix can be extracted out by debugging this flow.

Participation

I plan to provide a short daily update regarding the tasks on Zulip in order to align with the team and ask any queries if I'm blocked somewhere. The code would be updated regularly on my GitHub branch after forking from the Commons App GitHub Repo and would be merged to master branch after approvals.

About Me

I am Kartikay Kaushik, a second-year Computer Engineering Master's student at New York University. I will be graduating in May 2023.
I completed my B.Tech in Electronics and Communication Engineering from Indian Institute of Technology (IIT) Dhanbad, India in 2018.

In the Summer of 2022, I worked as a Software Engineering Intern at Nutanix, Inc., California, USA.

I worked for over 3 years at Amdocs Development Centre, Pune, India, and Guadalajara, Mexico from June 2018 - August 2021.

I have been contributing to open-source projects, particularly to Wikimedia Commons App since I got to know about it.

How did you hear about this program?

I got to know about the program while working on issues with Wikimedia Commons App.

Will you have any other time commitments, such as school work, another job, planned vacation, etc, during the duration of the program?

As of now, I do not have any other time commitments during the program and will be available to work on the project for as many hours as required.

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 applying only for the Google Summer of Code program and would not be applying for any other program or organization.

What does making this project happen mean to you?

Making this project happen means a lot to me because it offers a rare opportunity to contribute to a widely-used and impactful open-source project, while also gaining valuable skills and experience in software development. As a fervent user of android apps, I understand the importance of a reliable and user-friendly app. Addressing and fixing the bugs in the app will make it simpler for users to contribute high-quality images to Wikimedia Commons, ultimately benefiting all Wikimedia projects that rely on this image repository. Additionally, being a part of Google Summer of Code is an honor and an opportunity to work with experienced mentors and other contributors, learn from them, and grow as a developer. Overall, making this project happen means making a meaningful contribution to a valuable cause while also advancing my own skills and career.

Past Experience

Personal Projects
  • Multimodal Classification To Detect Hate Speech: As part of the project, we designed, developed, and trained a multimodal classification model on the Hateful Memes dataset. The challenge was initially organized by Facebook AI to detect hate speech in memes. The state-of-the-art methods to perform the classification are quite imprecise. We created our own multimodal models with different text and image classifiers and extended our dataset to improve the accuracy of the classification of memes into hateful or non-hateful. The model is then extended as a service where users can upload a meme and the application would inform the user if the meme is hateful or not.
  • Adversarial Attacks on Multimodal Classifiers: As part of the project, we attacked a multimodal classification model on the Hateful Memes and Memotion 7K dataset. The objective of the project is to minimize the classification accuracy by adversarially modifying the image and/or text of memes to maximise the misclassification of memes from hateful to non-hateful and vice-versa. Using the adversarially modified images and/or texts, the model was then re-trained to improve its robustness.
Relevant skills
  • Proficiency in Java and Kotlin
  • Understanding of Wikimedia APIs.
  • Experience with integrating RESTful APIs and third-party libraries in Android apps.
  • Ability to use debugging tools like the Android Studio debugger and familiarity with testing tools like JUnit.
  • Strong problem-solving skills, and ability to identify and analyze technical problems and develop effective solutions.
  • Experience with software version control systems, such as Git
  • Familiarity with working in an Agile development Environment.
  • Passion for contributing to open-source projects, and knowledge of how to work with the Wikimedia community.

Contributions to Wikimedia Commons

Issues
Issue Name Status
#4994[Bug]: F-Droid: GMS libs in the final apkClosed
#5154[Bug]: Remove Telemetry due to app's privacy policyClosed
#5158Upgrade Kotlin Version from 1.5.10 to 1.7.20Closed
#5165Mediawiki MobileView API deprecated, Mobile Content Service deprecated too, migrate to WMF-recommended solutionOpen
#5175Upgrade Minimum SDK Version, Compile and Target SDK VersionClosed
#5182Switch from Mapbox to MapLibreClosed
Pull Requests
PR Name Status
#5155Removed telemetry - Bug #5154Merged
#5164Fix:5158 Upgraded Kotlin Version from 1.5.10 to 1.7.20Merged
#5177Fix:5175 Upgraded Minimum SDK Version, Compile and Target SDK VersionMerged
#5184Fix #5182 Switch From Mapbox to MapLibreOpen

Event Timeline

Kartikay1412 renamed this task from Insert project title here to GSoC 2023 Proposal - Commons Android app - Make upload more reliable.Mar 23 2023, 11:51 PM
Kartikay1412 claimed this task.
Kartikay1412 updated the task description. (Show Details)
Kartikay1412 added subscribers: Kaartic, Nicolas_Raoul.

@Kartikay1412 You would need to elaborate a bit more on your proposal. Do checkout the details mentioned in this wiki page. You could also checkout other proposals for the project in Phabricator to get an idea on the structure of a good proposal.

@Kaartic Thank you for the input. The application is still in progress and I'll complete it by EOD today.

@Kartikay1412 would be able to mention what you plan on doing during the community binding period?

Do also mention a bit about your other experience with Android (projects if any / level of knowledge etc.). This is just to give us an idea :-)

Thank you @Nicolas_Raoul and @Kaartic for your suggestions. I've made the edits accordingly. Please let me know if there are any more points I need to add.

Hi @Kartikay1412, as the deadline for GSoC is quickly approaching in less than 48 hours (April 4th, 2023, 18:00 UTC), it's crucial that you submit your proposal on Phabricator and Google's program website in the recommended format as soon as possible. To avoid any potential last-minute rushes or server failures, we highly recommend that you submit your proposal early and keep updating it as needed before the deadline. Once you have submitted your proposal, please move it from the "Proposals in Progress" column to the "Proposals Submitted" column on the Phabricator workboard by simply dragging it. If you have any inquiries, please do not hesitate to ask. Good luck with your application!

@Nicolas_Raoul @Kaartic Apologies for the last-day reviews. Could you please check if my implementation strategy looks feasible?

It seems good for a start, overall.

I would also want to investigate whether there are any third-party libraries or APIs that can be integrated into the app to automatically add location data to images that don't have it or to preserve the location data during the upload process.

The "adding location data automatically" part is not ideal. We can't automatically add location data to the images since the location in which the pictures were taken could vary. To address cases where the image itself lacks a location, the app itself provides an option which allows the user to specify the location through a map during upload (IIRC). That should be enough to cater to those cases.

Task #5128: My initial approach would be to implement the approaches suggested in the issue description. On top of that, I have a few other ideas which may or may not be feasible.

  • Use a background service: Instead of relying on the user to keep the app open while the upload is in progress, we can use a background service to handle the upload. This will ensure that the upload continues even if the user switches to another app or locks their phone.

This one sounds interesting.

Use a different upload mechanism: If the current upload mechanism is unreliable, we can try using a different method such as FTP or SFTP. These protocols are designed for file transfers and might be more reliable in certain situations.

This is not likely going to work. AFAIK, Mediawiki does not support uploading via FTP / SFTP. We could only use the file upload API. Do correct me if I'm wrong.

Having said that, searching through the Commons / MediaWiki village pumps regarding this issue might give interesting insights. Also, seeking advice from the Wikitech-l mailing list would be a good idea.

Thank you so much for the detailed feedback @Kaartic, I'll make the changes accordingly. Also, is the current upload mechanism via File Upload API already?

This comment was removed by Kaartic.

Thank you so much for the detailed feedback @Kaartic, I'll make the changes accordingly. Also, is the current upload mechanism via File Upload API already?

Yes. IIUC, we follow the chucked upload strategy (see "Example 3: Upload file in chunks" in API:Upload wiki). See related code ( ref 1 ) ( ref 2 )

@Kartikay1412 We are sorry to say that we could not allocate a slot for you this time. Please do not consider the rejection to be an assessment of your proposal. We received over 100 quality applications, and we could only accept 9 applicants. We were not able to give all applicants a slot that would have deserved one, and these were some very tough decisions to make. Please know that you are still a valued member of our community and we by no means want to exclude you. Many applicants who we did not accept in previous rounds have become Wikimedia maintainers, contractors and even GSoC students and mentors this year!

Your ideas and contributions to our projects are still welcome! As a next step, you could consider finishing up any pending pull requests or inform us that someone has to take them over. Here is the recommended place for you to get started as a newcomer: https://www.mediawiki.org/wiki/New_Developers.

If you would still be eligible for GSoC next year, we look forward to your participation!