Proposal for the project [[https://phabricator.wikimedia.org/T185036 | Wikimedia Commons app : Feedback on how pictures uploaded to Commons are used]] for GSoC '18 internship.
## Profile
**Name:** Harisanker Pradeep
**IRC nickname on Freenode:** harisanker24
**Email id:** harisanker24@gmail.com
**Web Profile:** https://harisankerpradeep.github.io/
**Github:** https://github.com/harisankerPradeep
**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©right.
This will be achieved through two phases:
**Phase 1: Feedback on the usage of the uploaded images**
- 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)
**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 [[https://github.com/urbanecm/commonsmisc/blob/master/README.md | 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©right**
- Display tutorial again and implement a quiz, for users who have a high upload revert rate
**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
===Deliverables
|Period|Task|Deliverable
| ------ | ------ | ------
|April 23-May 14|Community 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 23|Identify the best API strategies that can be used. One of our contrbutors has made an [[https://github.com/urbanecm/commonsmisc/blob/master/README.md | 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 5|Implement asynchronous calls to the API's to obtain the required data. Incorporate the code with the existing data fetching infrastructure i.e AppacheHttpClientMediaWikiApi.java and other related files. Ensure that it doesn't affect the smooth functioning of other API calls| Commits. Code to fetch data from APIs will be committed
|June 6 - June 8|Begin building UI for the feature. Discuss the mockups and UI with the community and mentors|Commits, screenshots. Commits for the UI populated with dummy data will be committed
|June 9 - June 10|Wire the UI with the API data fetching code and populate it with actual data|Commits,screenshots. The app should now be able to fetch data from API and populate the UI|
|June 11 - June 15|Phase 1 evaluation|GSoC mandated evaluation|
|June 16 - June 17| **Buffer 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 19|Polish the UI|Commits,screenshots. Code for the UI will be polished|
|June 20 - June 24|Manual 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 issues|Commits, Pull request for phase 1 will be made. |
|June 25- July 2|Phase 2. Find a way to find users who need to be refreshed about topic©right. 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 5|Clean 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 any|Commits. Payloads and latency will be documented. Code to fetch the data from API will be written|
|July 6 - July 8|Begin 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 user|Commits/Screenshots. Code for the quiz will be commited|
|July 9 - July 13|Phase 2 evaluation|GSoC mandated evaluation |
|July 14 - July 16|**Buffer period. ** Make changes as suggested by the evaluation result|This is a buffer period and will be utilized if something goes wrong in the previous periods|
|July 17 - July 21|Modify the code to ensure that these features are only viewed by the users whose pictures qualify the above-mentioned metric|Data fetched from API's will be wired to the UI. Commits/Screenshots|
|July 22 - July 26|Manual testing, bug fixes. Make a PR to let other users give suggestions on the same|Commits, bugfixes. |
|July 27 - August 5|Bug fixes, Writing documentation and Updating appropriate guides. Code cleanup for submission.|Bugfixes. Documentation will be made up to date.|
|August 6 - August 14|Code Submission and Final evaluation|Code submission|
|August 14-August 24|Mentors submit a final evaluation |Will continue to work for the betterment of the app irrespective of the result.|
===Participation
- 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)
- Weekly reports will be published in my [[https://meta.wikimedia.org/wiki/User:Harisanker24 | meta wiki page]]
- 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 --> https://tinyurl.com/y994q55t , https://tinyurl.com/ybjoxm38 . 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 --> https://www.vidyalai.com/
- 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: https://github.com/commons-app/apps-android-commons/pull/1150