Page MenuHomePhabricator

Proposal: [Wikimedia Commons app] Feedback on how pictures uploaded to Commons are used
Closed, DeclinedPublic


Proposal for the project Wikimedia Commons app : Feedback on how pictures uploaded to Commons are used for GSoC '18 internship.


Name: Harisanker Pradeep
IRC nickname on Freenode: harisanker24
Email id:
Web Profile:
Location: India
Typical working hours: 11 am to 1 am (UTC + 5:30)

Note: Feedback is much welcomed.

Synopsis :

Wikimedia Commons Android app is an android application that allows users to upload pictures to the Wikimedia Commons directly from their device.

The project aims at improving the user experience of the app, by offering some feedback on how the uploaded images are used, and at educating the users more about topic&copyright.

This will be achieved through two phases:

Phase 1: Feedback on the usage of the uploaded images | Github discussion

  • Number of images used in Wikipedia/Wikivoyage/etc articles
  • Number of images that have been edited by someone else (including simple description typo fix and categorization)
  • Number of images that have been featured or received other kinds of awards
  • Received barnstars
  • Received thanks
  • Number of deleted images (must be with a link to the deletion discussion/reason)

Why this is important?

  • Slight gamification is scientifically proven to increase user engagement
  • Knowing how their photos were used will encourage them to upload more
  • Negative feedback on the photos will help them improve the quality of the pictures they upload
  • Lift the load from reviewers as the users now know what is expected of them.

Strategy for Phase1

  • Find the best API strategy. It should have no latency issues and the payload should be minimal. One of our contributors had implemented an API that performs all of the needs of this project. Explore the possibility of using the same.
  • Implement asynchronous calls to the selected API to fetch required data. Utilize the existing code infrastructure for performing the same.
  • Build the UI for the feature based on the mockups discussed in the community
  • WIre the UI with the API fetching code and populate it with actual data.
  • Debug and test the feature for various virtual devices

Phase 2: Educate users on topic&copyright | Github discussion

  • Display tutorial again and implement a quiz, for users who have a high upload revert rate

Why this is important?

  • Most users skip or do not understand the tutorial the first time. Showing the tutorial a second time followed by a quiz can improve the users understanding of topic&copyright
  • This combined with negative feedback can help the user improve the quality of his uploads. Care must be taken to ensure that the user does not feel discouraged

Strategy for phase 2

  • Find an efficient way to utilize the existing MediaWiki API's to find the number of reverted pictures
  • Build the UI for the quiz and tutorial. Decide, after discussion with the community, on the content of the quiz. If the user answers a question incorrectly the app should show an explanation for the answer.
  • Compare the number of reverted pictures with the threshold number of reverted pictures an show tutorial and quiz to those users
  • Debug and test the feature for various virtual devices

Mentor: @maskaravivek
Co-mentor: @josephine_l


April 23-May 14Community bonding period. Discuss with the community on how the UI should work. Designing UI mockups for the interface plus general discussion on the MediaWiki API's to be used. I have my end semester exams from April 29 to May 8.Mockups of UI for both the phases will be discussed/confirmed and updated on the phabricator/issue page
May 15- May 23Identify the best API strategies that can be used. One of our contrbutors has made an API that does almost the same thing. Go through the possibility of usin the same.Document the payload and latency.Best API strategy for phase 1 will be confirmed and all important data will be documented
May 24 - June 5Implement asynchronous calls to the API's to obtain the required data. Incorporate the code with the existing data fetching infrastructure i.e and other related files. Ensure that it doesn't affect the smooth functioning of other API callsCommits. Code to fetch data from APIs will be committed
June 6 - June 8Begin building UI for the feature. Discuss the mockups and UI with the community and mentorsCommits, screenshots. Commits for the UI populated with dummy data will be committed
June 9 - June 10Wire the UI with the API data fetching code and populate it with actual dataCommits,screenshots. The app should now be able to fetch data from API and populate the UI
June 11 - June 15Phase 1 evaluationGSoC mandated evaluation
June 16 - June 17Buffer Period .Make changes according to the evaluation, in case the changes cannot be made during the evaluation period itself.Commits/Screenshots. In case something goes wrong in any of the above time periods this will make up for it
June 18 - June 19Polish the UICommits,screenshots. Code for the UI will be polished
June 20 - June 24Manual testing of the code, bugfixes. Since this phase is independent of phase 2 a PR will be made to enable other users in the community to check the code and make suggestions and point out issuesCommits, Pull request for phase 1 will be made.
June 25- July 2Phase 2. Find a way to find users who need to be refreshed about topic&copyright. The discussion in bug#274 in the GitHub repo suggests a threshold percentage on the number of reverted photos. If this is the chosen metric find an efficient way to use the existing MediaWiki APIs to find the number of reverted pictures.Commits. API strategy for this phase will be finalized
July 3- July 5Clean up the code to fetch the metrics. Record latency and payload for the same. Check if any fine-tuning is possible for latency issues if anyCommits. Payloads and latency will be documented. Code to fetch the data from API will be written
July 6 - July 8Begin working on the UI. Discuss with the community on what should go on the tutorial and the quiz that'll be used to evaluate the understanding of the userCommits/Screenshots. Code for the quiz will be commited
July 9 - July 13Phase 2 evaluationGSoC mandated evaluation
July 14 - July 16Buffer period. Make changes as suggested by the evaluation resultThis is a buffer period and will be utilized if something goes wrong in the previous periods
July 17 - July 21Modify the code to ensure that these features are only viewed by the users whose pictures qualify the above-mentioned metricData fetched from API's will be wired to the UI. Commits/Screenshots
July 22 - July 26Manual testing, bug fixes. Make a PR to let other users give suggestions on the sameCommits, bugfixes.
July 27 - August 5Bug fixes, Writing documentation and Updating appropriate guides. Code cleanup for submission.Bugfixes. Documentation will be made up to date.
August 6 - August 14Code Submission and Final evaluationCode submission
August 14-August 24Mentors submit a final evaluationWill continue to work for the betterment of the app irrespective of the result.


  • All the code will be regularly committed on my fork of the repository and pull requests will be made when a feature is completed. I'm quite familiar with git and have made some contributions to the repository.
  • Short daily reports will be made on the phabricator page and long milestone reports will be made as needed
  • Online on the IRC and Hangouts in my working hours (11 am - 1 am UTC + 5:30)
  • I have created a blog where I will be posting about the things I learned during my time with the organization

About Me

Education completed:
I'm a sophomore at Indian Institute of Technology Madras pursuing B Tech in Engineering Physics.

How did you hear about this program?
Heard about this program from a senior in college who worked on Wiki Ed Dashboard last summer.

Will you have any other time commitments, such as school work, another job, planned vacation, etc., during the duration of the program?
The odd semester starts in the first week of August but will no effect my participation as there are no quizzes during this period.

What drives you? What makes you want to make this the most awesomest wiki enhancement ever? What does making this project happen mean to you?
I got into coding because it enables me to create and I believe that's the case with many of my fellow developers. I feel that it's the urge to create that makes us human and coding is something that enables millions of people out there to do the same. I wouldn't have been able to work on the things I work on today if it weren't for the many good-hearted people out there who were willing to share the code they wrote. I feel that, being a product of such an attitude towards technology, that I'm morally obliged to contribute towards the open source community. I want to help more people explore this wonderful world of opportunities and develop better technologies through shared knowledge acquisition.

What inspired me to work on this project is the impact it creates on the people who use the app and people who use the images uploaded through the app. To contribute to an organization, Wikimedia, whose mere existence is integral to every person of all age groups starting from a middle schooler doing his history project to a scientist flashing through a wiki page for as a quick refresher on some topic is truly a dream come true.

Past Experience

  • I'm code primarily in Java and Javascript but over the past few months, I have developed a liking towards Kotlin.
  • I built the technology stack for a smart bike sharing program in a college that let students use a mobile app to open the smart locks on any of the shared bikes. As it turned out it was the first in the country. You can read more about it here --> , . It required me to develop a good understanding about the bluetooth functionality of android phones ,particulartly Bluetoothe Low Energy(BLE), and GATT protocol. The biggest challenge was to run a service in the background that maintained an open BLE connection with the smart device and how to restart the service and restore state in case OS decides to kill the service. Since some of the communications with servers had to be realtime the project required me to profile the app and make sure that the payload was minimal and there were no latency issues. At the same time if the connectivity was lost due to some reason the app had to cache the valuable inforation collected. Looking back, it was a really intresting experience.
  • I have built a chat app for an online tutoring platform, called vidyalai, that connects college students who are willing to teach to school going students . It utilizes web sockets to maintain an open connection between devices to create chatroom. The messages are stored in another database for viewing later. The app used Google Cloud Messaging (GCM) for push notifications to let the app know that a new message has been received. Check it out here -->
  • I also contribute to other FOSS projects which include Firefox Focus and Rocket.Chat

Microtasks completed

Over the past few months I have completed a couple of microtasks. The one I put the most effort into was an enhancement that enabled the app to pick location data from pictures that were clicked around the same time--> the PR can be viewed here:
Other contributions

Event Timeline

harisanker24 renamed this task from Proposal: Feedback on how pictures uploaded to Commons are used in Wikimedia Commons app to Proposal: [Wikimedia Commons app] Feedback on how pictures uploaded to Commons are used .Mar 12 2018, 6:17 PM

Hi @harisanker24 ,

Glad to see that you are working on your proposal. :) I especially like the detailed task breakdowns - it's great that you have suggested documenting the results of various API strategies, and mockups for each UI phase.

A few suggestions from me:

  • I suggest linking the relevant GitHub issues in each phase, and going into a bit of detail as to the "why" of implementing them, not just the "how".
  • If you have completed more than 1 microtask, I would suggest linking all of them here so that we don't have to search through your PRs to find the others. You can still keep the part about #1150 being your best one. :)

Thanks @josephine_l ! I'll make the necessary changes.

Hello @harisanker24 ,

Nice to see that you have submitted a proposal for the project. Your past work looks really interesting :)

A few suggestions:

  • The timeline proposed by you can be elaborated a bit more to make the points clear
  • I see the Deliverables in most of the sections is Commits/Screenshots. It would be great if you could think of the deliverable in the context of the subtask picked.
  • Before the timeline section, it would be great if you could add in detail the approach that you would be following for each of these phases.

@maskaravivek Thanks for your feedback. I've made some changes accordingly.