Grants:Project/Commons app/Commons Android app v3

This project is funded by a Project Grant

proposal

people

timeline & progress

finances

midpoint report

final report

statusselected

Project Grants

Improve Commons Android App

summaryVersion 3.0 of Commons mobile uploader with increased app stability, improved Nearby feature, limited connectivity mode, and better outreach to underrepresented communities

targetWikimedia Commons (primarily); geolocated Wikidata items and Wikipedia articles lacking images

type of granttools and software

amount62,900 USD

grantee• Misaochan• Neslihan_Turan• Maskaravivek• Ashishkumar468

advisor• Syced• DBrant_(WMF)• Vojtěch_Dostál

contact• josephinelim86@gmail.com• nicolas.raoul@gmail.com

volunteer• domdomegg

organization• Commons app (group)

this project needs...

volunteer

created on12:00, 29 October 2018 (UTC)

Friendly space expectations

Project idea

What is the problem you're trying to solve?

What problem are you trying to solve by doing this project? This problem should be small enough that you expect it to be completely or mostly resolved by the end of this project. Remember to review the tutorial for tips on how to answer this question.

The Wikimedia Commons app allows contributors to quickly and easily upload photos to Commons from their mobile (Android) phone, without needing to use a browser or a computer. Initially created by WMF and abandoned in 2014 due to lack of resources for maintenance, the app was restarted by the community in 2015 and has been maintained as an open-source project on GitHub by grantees and volunteers ever since. We successfully completed an IEG (Individual Engagement Grant) in 2017, and were later approved for a second grant which is now close to completion, pending the release of v2.9 to production (for release history, see midpoint report, and blog posts for v2.6, v2.7, v2.8 and v2.9 beta).

As of 5 Nov 2018, we have 4058 active installs, and a total of 15,167 distinct images (15.91% of all images) uploaded via our app have been used in Wikimedia articles. In the last 6 months alone (May - Oct 2018), 21,241 files were uploaded via our app, and only 1738 (8.2%) of those files required deletion.

• 
  Quarterly uploads and deletions as of 13 Nov 2018 (2018 Q4 still in progress)
• 
  Active installs as of 5 Nov 2018
• 
  Main screen of Commons app (v2.9 beta)
• 
  Upload screen, first step (v2.9 beta)
• 
  "Nearby places that need photos" feature (v2.9 beta)
• 
  Trip down memory lane: Upload screen in Feb 2016
• 
  Trip down memory lane: Initial prototype of "Nearby places that need photos" feature in Sep 2016

Now that we have a solid mobile upload tool and a growing userbase and community around it, we would like to start focusing on our strengths as a mobile uploader:

• Providing a convenient and stable Commons upload tool for all mobile users, especially for those living in the Global South - where Commons editors are fewer, and mobile phone usage and ownership (specifically, Android-based phones) typically greatly exceeds PC usage/ownership. For instance, more than 50% of Asian and African internet users do not access the internet on a PC.
• Seamlessly guiding the user to go to locations that need photos, and upload photos for those locations, via a simple and interactive process.

There are a few barriers that stand in the way of achieving this:

• A large portion of our codebase is based on sparsely-documented legacy code from the very first incarnation of the app 5 years ago (a long time in the Android development world), leading to unpredictable behavior and bugs sometimes. In our last grant, we eventually found ourselves in a position where new features built on top of legacy code were causing other features to not work correctly, and even fixes to those problems sometimes had side effects that caused other problems. For instance, we were plagued by sporadic upload failures that were very difficult to debug, which slowed progress for a long time and caused inconvenience to users.
• The direct photo upload via "Nearby places that need photos" feature has not yielded as many Wikidata p18 edits as we had hoped for (we had hoped for 500, but as of 9 Nov 2018 we only had 168). Based on user feedback, the feature has a few bugs (for instance, sometimes a successful upload does not edit p18), and lacks several quality-of-life features that they would need in a photo trip app. Also, currently there is no easy way for users to add their photos to the Wikipedia articles lacking them.
• User acquisition in the Global South is not as high as it could be due to the fact that our app does not work well with limited connectivity (which is a common problem in developing countries), as well as lack of outreach.

What is your solution to this problem?

For the problem you identified in the previous section, briefly describe your how you would like to address this problem. We recognize that there are many ways to solve a problem. We’d like to understand why you chose this particular solution, and why you think it is worth pursuing. Remember to review the tutorial for tips on how to answer this question.

We intend for the Commons app to undergo significant development in 2019, culminating in the release of v3.0. This version will contain several improvements, with the most important few listed below:

• To increase app stability and code quality: We will overhaul our legacy backend, reduce complexity and dependencies in our codebase, and introduce test-driven development for the first time.
• To boost targeted acquisition of photos for places that need them: We will improve the "Nearby places that need photos" feature (e.g. by implementing filters and bookmarks) and fix a few outstanding bugs to make it more user-friendly and convenient to use. We will also complete the final link in the chain of collecting photos for Wikipedia articles that lack them by prompting users to add their recently-uploaded picture to the relevant Wikipedia article.
• To increase user acquisition in the Global South: We will implement a "limited connectivity" mode, allow pausing/resuming of uploads, and put more time and effort into outreach and socializing the app, especially to underrepresented communities.
• We also wish to continue to assist the Commons community to reduce vandalism and improve usability of images uploaded. This will be done by implementing selfie detection, and a "to-do" system that reminds users if an image lacks a description/categories.

Project goals

What are your goals for this project? Your goals should describe the top two or three benefits that will come out of your project. These should be benefits to the Wikimedia projects or Wikimedia communities. They should not be benefits to you individually. Remember to review the tutorial for tips on how to answer this question.

• A more stable Commons mobile uploader with a modern codebase, lower code complexity, higher test coverage, and fewer bugs and crashes
• Encouraging the upload of high-quality and usable images by mobile users, especially for Wikipedia articles that lack photos
• An increased number of Commons contributors, especially from the Global South

Project impact

How will you know if you have met your goals?

For each of your goals, we’d like you to answer the following questions:

1. During your project, what will you do to achieve this goal? (These are your outputs.)
2. Once your project is over, how will it continue to positively impact the Wikimedia community or projects? (These are your outcomes.)

For each of your answers, think about how you will capture this information. Will you capture it with a survey? With a story? Will you measure it with a number? Remember, if you plan to measure a number, you will need to set a numeric target in your proposal (i.e. 45 people, 10 articles, 100 scanned documents). Remember to review the tutorial for tips on how to answer this question.

Outputs:

• All tasks in project plan completed
• Commons app v3.0 released on Google Play Store and F-Droid

Outcomes:

• Open bug issues on GitHub reduced by 30% from the start of the grant (Number of open bug issues as of 18 March 2019: 80)
• A crash rate of <1.0% (less than 10 crashes per 1000 devices) in v3.0. This metric is an indicator of app stability, and will be measured via data obtained from the Google Play developer console 2 weeks after the final version is released to production. (Crash rate in v2.8.5 as of 23 Nov 2018: 16 crashes per 1000 devices)
• At least 25% code coverage (the percentage of code which is covered by automated tests). This metric is a predictor of app stability in future releases, as failing tests provide early warning of issues with new code. It will be measured after completion of the grant via Codecov reports that are already integrated with our GitHub repository. (Code coverage as of 9 Nov 2018: 4.37%) Note: It may be worth noting that industry standards tend to fluctuate around 80-90% . However, those standards are mostly applicable to software where test-driven development has been in place since the very beginning, not software that already exists and that had minimal tests to begin with. Aiming for 80% in this grant will not be realistic for us, but that will be the eventual goal. It is also worth noting that we strongly encourage volunteer code contributions, and thus will not require unit tests for the code that volunteers submit in order to reduce the barrier of entry, so that will dilute our coverage. It is a tricky balance.

Do you have any goals around participation or content?

Are any of your goals related to increasing participation within the Wikimedia movement, or increasing/improving the content on Wikimedia projects? If so, we ask that you look through these three metrics, and include any that are relevant to your project. Please set a numeric target against the metrics, if applicable.

• A total of >20,000 distinct images uploaded via the app are used in Wikimedia articles. This metric defines not just the number, but also the usability of images uploaded via the app, and will be measured via a GLAMorous query. (Total distinct images as of 5 Nov 2018: 15,167)
• A total of >700 places that need photos will have photos added to them via the app. This metric indicates the user-friendliness and effectiveness of the "Nearby places that need photos" feature improvements, and will be measured at the end of the grant by querying the number of P18 edits made in Wikidata by our app (an edit is made automatically to the corresponding Wikidata entity whenever anyone uploads an image via the Nearby feature). (Total number of P18 edits as of 9 Nov 2018: 168)
• >50,000 new images uploaded to Commons via the app throughout the grant duration, while maintaining a deletion rate of <10%. We are happy with the deletion rate (8.2%) in our last 6 months, and now we would like to attempt the challenge of maintaining this rate while simultaneously encouraging an increase in Commons contributions through the app. This metric would define the success of our new features focused on user-friendliness and vandalism reduction. Both of these numbers will be measured via analysis of data from the Commons app stats tool at the end of the grant.
• A total of >5000 active installs on Google Play. This metric indicates the effectiveness of outreach and socializing of the project, and the number of active installs will be obtained from the Google Play developer console at the end of the grant. (Total active installs as of 5 Nov 2018: 4058)
• At least 30 new Commons contributors from Global South countries via workshops. This metric indicates the effectiveness of the workshops that we plan to organize, and will be measured by the number of new users who sign up during those workshops.

Project plan

Activities

Tell us how you'll carry out your project. What will you and other organizers spend your time doing? What will you have done at the end of your project? How will you follow-up with people that are involved with your project?

What will you and other organizers spend your time doing?

We have a team of four part-time Android developers who will share these tasks (individual task allocation is discussed further in the Budget section):

• Design and development of the planned features
• Testing - both manual testing and writing of unit tests
• Publishing releases on Google Play Store and F-Droid
• Communicating with users on a regular basis to obtain feedback and bug reports
• Fixing any issues with releases
• Supporting and fostering volunteer code contributors
• Outreach and socializing project

As usual, all of the code for the app will be publicly available on our GitHub repository under the open source Apache License 2.0.

What will you have done at the end of your project?

Our project plan is divided into 5 main areas of focus. Each area of focus has several tasks associated with it, and most of the tasks already have an issue on our GitHub repository, which is linked via its issue number.

Part 1: Increase app stability and code quality

A major issue that we faced in our last grant was that the time spent troubleshooting, diagnosing, and fixing bugs increased exponentially as the app grew, and eventually equaled the time spent actually developing new features (which led to our last grant taking double the time that was anticipated). There were a few common root causes of this phenomenon:

• Much of our core backend code is still based on its original incarnation from 5 years ago (a long time in the Android development world). This results in using deprecated libraries and API calls, not adhering to modern best practices, and lack of standardization as we have a patchwork of old and new code
• More new features resulted in more code, greater app complexity and more potential areas for bugs
• More users, especially in a userbase with devices and versions as diverse as Android's, resulted in more bugs being discovered
• Buggy pull requests by well-meaning new volunteers - we do our best to test all PRs but bugs do slip through, and we were not very vigilant with monitoring new libraries added by volunteers
• We have a high number of third-party components and libraries in our app, thus increasing complexity and the potential for difficult-to-solve bugs and crashes down the road
• Android updates by Google that render code obsolete or introduce problems - for instance the new Oreo release caused frequent crashes for users until we managed to isolate the cause

Some of these causes are unavoidable (more users and more new volunteers is always good, and Android updates are inevitable), but others can be tempered with better software development practices and stricter code quality measures. Thus, we learned two very valuable lessons from our last grant: (1) we need a more solid and consistent foundation to build new features on, and (2) feature/userbase expansion needs to be tempered with technical and code quality improvements that aid maintenance. The improvements below are aimed at achieving that goal.

• Overhaul legacy backend code and reduce code complexity. Some of our priorities in this regard are listed below. (#1092 and #1863)

• Replace all usages of the deprecated org.mediawiki:api library with Retrofit (plus RxAndroid) for network calls, which will also remove our reliance on the outdated yuvi:http.fluent and org.apache.http.legacy libraries. User:DBrant_(WMF) has informed us that the Wikipedia app team are working on packaging their network code into a standalone library that adheres to these best practices and will be usable by other apps, so we will use their library to simplify this implementation once it is ready.
• Refactor all AsyncTasks to use RxAndroid instead, for consistency
• We have already implemented a stricter process for including new libraries in pull requests, and we will now go through all our existing dependencies to see if we should keep or remove them, and refactor the code accordingly.
• Refactor our content providers to adhere to modern standards, and eliminate hardcoded column positions
• Consolidate our multiple SharedPreferences databases into one
• Clean up all string literals in code and replace them with string resources, to better take advantage of TranslateWiki translations
• Overhaul our authentication system, which has been the culprit of several failed upload issues (the issues have been mostly patched up, but still happen occasionally, i.e. the foundations are shaky). We will investigate how the authentication flow can be simplified, and take a look at how we are handling edit tokens (the usual cause of failures).

• Introduce test-driven development (TDD) to our development cycle. TDD is a software development process where requirements are turned into very specific test cases, then the software is improved to pass the new tests. This helps ensure that code is written with testability in mind, and that tests for every feature get written. Writing tests first is also said to lead to a deeper and earlier understanding of the product requirements, ensures the effectiveness of the test code, and maintains a continual focus on software quality. We will start by implementing this process for all grant tasks involving backend development (UI views are more difficult to test and the effectiveness is debatable). Volunteer code contributions will not be required to adhere to TDD, as we want to lower the barrier of entry for volunteers as much as possible. Implementing TDD does increase the time estimates for each grant task, but we anticipate that the positive results on app stability and code quality will be worth it. (#1883)

• Write a script to automate uploading to the Commons Beta server. Currently, whenever we do a release, developers manually test uploading via the various workflows available in the app, to ensure that our core functionality is not broken. A script that performs the testing for us would reduce the time needed for each release (we would use the Commons Beta server for this purpose to avoid spamming the real Commons with bad pictures).

• Further reduce existing bugs and crashes. A major issue that affected the time that we took to complete our last grant, was that the 3 part-time developers had to split their time between implementing the new features proposed in the grant, while simultaneously fixing any problems that cropped up. While we anticipate that the improvements above will reduce the time needed for fixing bugs in the future, realistically there will still be some that slip through, and we have a huge backlog of existing bugs that need to be dealt with. Our solution is to add a 4th part-time Android dev in this grant - they would focus on bugs and crashes, thus reducing our backlog and also allowing the other 3 devs to focus on grant tasks and (hopefully) complete this grant in a more timely manner.

Part 2: Targeted acquisition of photos for places that need them

Screenshot of Nearby feature, with an item on the map selected and expanded

These proposed tasks revolve around our "Nearby places that need photos" feature (or "Nearby" in short). A brief walkthrough for those unfamiliar with the feature: Currently, the Nearby feature displays a map/list of Wikidata items that lack a p18 image. Users can currently upload pictures directly via this feature, which pre-fills the image title with the name (label) of the Wikidata item, suggests categories based on that item, and then edits the p18 property if the image upload succeeds.

• Add filters to Nearby to allow users to filter for certain types of Wikidata items. Users have different preferences for photo trips, and may want to avoid (or specifically look for) historic buildings, parks, streets, etc. On the other hand, some may want to focus on uploading photos for Wikidata items that already have Wikipedia articles, rather than those that do not have articles. We plan to implement filters that will make it easier for users to plan photo trips around their preferences. (#1450)

• Allow users to bookmark Nearby items that they plan to submit pictures for, and to view all their bookmarked items on the map. In v2.10, users will be able to search for Nearby places anywhere on the map instead of just around their current location. We anticipate that users may find themselves looking at Nearby items that they are interested in taking photos of (e.g. for their photo trip tomorrow), but there is no convenient way for them to save and view all those items on their map. We intend to expand our rudimentary Bookmarks system to allow users to view all their bookmarked places on the Nearby map all the time (regardless of search area), whenever they load it. This feature will also provide the foundation for future enhancements like suggesting itineraries for photo trips. (#1499)

• When user uploads a picture with a geotag, check for Nearby items around that location, and if we find any, ask user "Is this a picture of Place X?" When the user selects an image to upload, we would run an asynchronous Wikidata query that searches for a place that needs pictures in a 100m radius of the image's coordinates. If any are found, we would pick the closest one and display in the UI "Is this a photo of Place X"? If the user says Yes, we would pre-fill the title and description fields for them, and associate their upload with that Wikidata item (as if they had done a direct upload from Nearby), with appropriate category suggestions and p18 edits. This would be beneficial for users who don't use the Nearby feature to plan their photo trips, but still happen to take and upload a relevant photo. (#259)

• After uploading a photo via Nearby, if a Wikipedia article exists for it and that article has no relevant images, prompt user to add their recently-uploaded picture to the relevant Wikipedia article. Now that users can upload photos directly via the app for places that need pictures (via editing the p18 property of that Wikidata item), this feature would complete the final link in the chain of seamless workflow. After uploading the photo and editing the p18 property, we would use the /page/media Restbase API to check if the associated Wikipedia article has relevant images. If it has none, we would have an icon next to that image recommending that the user add their picture to the article, and tapping the icon would bring them to the Wikipedia web editor with basic instructions of what to do, and the wikicode for that image automatically copied to their clipboard. (#872)

• Fill P2096 (media legend) of Wikidata item using metadata typed by user. When the user uploads an image via Nearby and the p18 property of the associated Wikidata item is edited, we would also insert the title and description of the image into the P2096 property of that Wikidata item. Infoboxes could then read this description when transcluding images from Wikidata. (#1831)

• Track number of p18 edits made by user and include them in Achievements screen. Users will then be able to see the number of photos they have added to places that need them, which could motivate them to upload more photos through this feature.

• Fix issues with p18 edits not working and user location not being found. According to reports from our users, p18 edits sometimes fail, even though the upload of the image itself succeeds. There have also been a few reports of cases where Nearby is unable to find the user's location, even if other map apps are able to do so. We will perform an in-depth investigation of these issues and fix them. (#1866)

Part 3: Increase diversity of Commons contributors

The gender gap and geographical gap among Wikimedia editors is a persistent issue - as mentioned in a Wikimedia blog post from Feb 2018:

"Wikipedia’s gender gap has been well-publicized since at least 2011, when surveys indicated that well under 20% of Wikipedia’s editors identified as female—one survey even put it at less than 10%.

Other gaps in contributor diversity have been somewhat less-well publicized, especially Wikimedia’s global gaps. We know that as of 2015, only 20% of Wikipedia’s editors come from the Global South (broadly, Asia, Africa and Latin America). Skews in our contributor demographics may have been understandable when Wikipedia started—it did begin with a handful of broadly white men in the United States, after all—but current contributor demographics today don’t reflect the realities and needs of the internet in 2018. 75% of the online population today is from the Global South, and 45% of those online are women. We are missing out on contributions from the African continent, from indigenous people, from women and transgender people, and many others. Without them, we cannot build the sum of all human knowledge."

We at the Commons app would like to try and do our part to try and help address this gap, at least for Commons contributors.

Geographical diversity

Installs of Commons app by country over the entire lifetime of the app as displayed in Google Developer console on 20 Nov 2018, zoomed in

Looking at statistics from the Google Play developer console, we can see that we have a wide distribution of users across the globe, with the majority of Global South countries being represented. We can also compare our current statistics to a snapshot of user distribution from July 2017, and see that we have achieved a wider coverage of Global South countries since then - for instance, in July 2017 there were only a few African countries represented, whereas currently almost all of them are represented.

To take advantage of this momentum, we would like to work further on increasing our userbase in the Global South. We know that mobile phone usage and ownership (specifically, Android-based phones) typically greatly exceeds PC usage/ownership in the Global South, so this is a user population that the Commons app is inherently well-suited for.

• Implement "limited connection" mode and allow pause/resume of uploads. Currently, the app is not very suitable to be used in locations where Wi-Fi is spotty and mobile data is limited. Losing a connection halfway through an upload means that the upload will fail, there is no way to pause and resume uploads, and no way to manage the amount of data that you want to spend on viewing your own contributions. A "limited connection mode" (that the user can toggle on and off as they wish) would automatically pause uploads until Wi-Fi is detected, and not download any images (i.e. thumbnails of previous contributions). So for instance a user with a limited mobile data plan could browse the list of Nearby places that need pictures, find one near her and take a photo of such a place, and "upload" it with a title, description and categories. The upload would be queued and would automatically resume once she uses her device in a location with Wi-Fi. Also, a user with spotty Wi-Fi connection would not need to worry if she loses connection halfway through an upload, since the upload progress would be saved. This will be useful to everyone, but especially for people in rural areas and/or the Global South where public Wi-Fi is rare and mobile data is limited and/or expensive. (#746)

• Organize outreach workshops. We intend to hold a couple of local workshops to teach people how to use the app to contribute to Commons, with focus on Global South locations. All travel will be local only (2 of our grantees live in Global South countries and we have multiple other volunteers in those countries), we will look for free/cheap places to hold it (e.g. a room at a local library or university), and it is expected that people will bring their own Android mobile phones (the majority of mobile users in the Global South use Android phones). All of this will ensure that costs will be kept low - we anticipate the total cost for 2 workshops to not exceed USD 400. A friendly space policy will be in place during these workshops. If this idea is successful, we will iterate on it in the future. (#1871)

Gender diversity

Based on findings by WMDE in their "Charting Diversity" report, key action points for improving gender diversity include: (1) image and communication campaigns, and (2) informational/educational films. As mentioned in the report, "It would also be important to focus on presenting images of female and male editors as well as editors with other gender identities (such as LGBTTI). This would generate more robust role model functions for other potential authors and focus on previously underrepresented groups."

• Create and publish video of diverse app users. We will create a video of a diverse range of participants talking about our app and using the app to document the world around them, especially via the Nearby feature. Our grantees include 2 women and a range of nationalities, so we will start with that, and we will ask for volunteers in our GitHub community or on Wikimedia mailing lists to participate as well. The video will be basic as none of us are professional videographers (unless we manage to find a volunteer professional video editor), but it should be sufficient for its purpose. We will then put the video up on our wiki, Play Store page, website, and blog. (#1473)

Part 4: Further reduce deletion rate & increase usability of images uploaded

• Detect selfies in uploads. (Or more specifically, detect faces that constitute more than a certain % of the image). One of the main concerns about a mobile uploader is the affinity of mobile users towards taking (and uploading) selfies, which are essentially useless in Commons. While this only constitutes a small percentage of images uploaded via our app, it is still worth taking steps to further reduce that risk. Using the built-in Android FaceDetector library, we will detect if the image uploaded by a user has a face that constitutes more than a certain % of the image, and warn the user that only pictures of notable people are allowed in Commons. In the future, we can consider increasing the strictness (e.g. only allowing uploads of faces by users with a certain number of uploads and/or revert %) depending on how reliable the real-life results turn out to be. (#74) 30 Nov 2018: It has been suggested to us on our discussion page that this may discourage users from uploading non-selfie images of people. Instead, we may consider an alternative implementation involving detecting whether a photo was taken with the front camera. (#1898)

• Allow users to modify or add categories/descriptions afterwards. Currently, users can only modify and add descriptions and categories to an image via the app during an upload - once the image has been uploaded, there is no way to modify it within the app itself. Implementing this would make it more convenient for users to make any necessary modifications, and a good description and categories would increase image usability. (#161)

• Implement "to-do" system for contributions. We would like to have a "to-do list" that reminds users about: (1) images that they uploaded with no categories or descriptions, and (2) images that can be added to associated Wikipedia articles that have no pictures. The user would be able to filter their contributions list by 'action required' to show only these images, and even if the user doesn't filter, there would be an indicator (perhaps an icon on the bottom right of an image) for actions required. (#1870)

Part 5: New main screen UI

After the new features have been completed, we would like to tie everything together in a new main screen UI. Since the creation of the app, the focal point of the main screen has been the user's past contributions. However, the app is now very different from what it was at the beginning - we have the Nearby feature, an Achievements screen with a level badge and upload stats, a Notifications screen with user talk messages, an Explore screen that lets users browse other Commons photos, and various other conveniences. At the end of 2018 we will be able to display news about an ongoing campaign. And at the end of this proposed grant, we will have a limited connection mode, the option to pause and resume image uploads, and a "to-do" system.

When the time comes, we will create a few different mockups and seek community feedback on which one they like best, before proceeding with implementation. However, as a rough guide, a possible plan for a new main screen UI is outlined below.

The action bar (the blue bar at the top of the screen) could have:

• Unread notifications as a bell icon
• Limited connection mode toggle

A bottom navigation bar with:

• Home
• Nearby (nearby places that need pictures)
• Browse (the current "Explore" screen)
• My contributions

Home (which will be the new main screen) could contain:

• "Welcome back, username!" with level badge, upload stats and achievements displayed
• News about ongoing campaigns
• The nearest place that needs pictures
• The picture being uploaded currently (with option to pause/resume) and queue of other pending uploads. Or, if there is no picture being uploaded or in the queue, the most recent picture uploaded
• "To do list" of uploaded pictures with action needed
• Upload button

All of this will culminate in the release of v3.0 of the app at the end of the project.

How will you follow-up with people that are involved with your project?

After v3.0 is released, we will focus on socializing the app. Wikimedia Czech Republic has volunteered to assist with outreach and socializing the project, and they have helped us greatly with our social media presence this year. Some of the planned avenues for socializing the project are listed below:

• Hold workshops to teach people how to use the app to contribute to Commons (this is elaborated on in Part 3: Increase diversity of Commons contributors)
• Put up a video showing a few people using Nearby to document the world around them (this is elaborated on in Part 3: Increase diversity of Commons contributors)
• Prepare a list of "things people need to know" about using the app to upload to Commons (and perhaps instructions on how to do a videocast), then spread the word to other Wikimedia chapters. This will assist other chapters to set up workshops in their own countries if they are inclined to do so.
• Update our website and Play Store listing with v3.0 screenshots
• Write a blog post for the Wikimedia blog, if approved by the blog team

Other methods for ongoing community engagement are described in the Community Engagement section.

Budget

How you will use the funds you are requesting? List bullet points for each expense. (You can create a table later if needed.) Don’t forget to include a total amount, and update this amount in the Probox at the top of your page too!

The total amount requested is 62,900 USD for 12 months.

Budget breakdown

Development

62,500 USD for grantee salaries (4 part-time developers)

Grantee	Role	Job description	Commitment	Person-weeks	Cost
Josephine	Project & product manager Android developer	Responsible for the entire project, product quality, and meeting grant reporting requirements Managing app releases, communicating with users, integrating user feedback Planning, coordinating and documenting work on the app Android development	25 hrs/week	46 weeks	28,750 USD(1)
Neslihan	UI designer & developer (Android) Assistant project manager	UI design & development (Android) Managing code repository - testing and reviewing pull requests, organizing issues and crash reports Supporting new contributors and volunteer collaborators	22 hrs/week	50 weeks	16,500 USD(2)
Vivek	Android developer	Android development	15 hrs/week	50 weeks	11,250 USD(3)
Ashish	Android developer	Android development	10 hrs/week	50 weeks	6,000 USD(4)
				Total	62,500 USD

(1) Based on salary of 25 USD/hr (to cover living costs in Australia).

(2) Based on salary of 15 USD/hr (to cover living costs in Turkey).

(3) Based on salary of 15 USD/hr (to cover living costs in India).

(4) Based on salary of 12 USD/hr (to cover living costs in India).

Outreach

400 USD to cover local travel and potential venue hire costs for 2 workshops in Global South countries

Total

62,900 USD

Community engagement

How will you let others in your community know about your project? Why are you targeting a specific audience? How will you engage the community you’re aiming to serve at various points during your project? Community input and participation helps make projects successful.

Our team at the Prague pre-hackathon preceding Wikimedia Hackathon 2017

Our community engagement plans specific to this grant are detailed in "4.1.3 How will you follow-up with people that are involved with your project?". Aside from those, these are the more general methods that we use on an ongoing basis to engage with the community:

• GitHub - Our source code is publicly available on GitHub under the Apache License 2.0, and anyone is welcomed to fork and contribute to our repository. Also, most of our new features/improvements and details of their implementation are discussed publicly on GitHub.
• Mailing lists and village pump - After major releases, I will usually post on the wikitech-l, mobile-l, commons-l and wikivoyage-l mailing lists, as well as on the Commons village pump.
• Tech News - We often post a summary of major releases on Tech News.
• Google groups forum - This forum is mostly used for bug reports and feedback from users who don't use GitHub.
• Social media - We have a Facebook and Twitter page which are regularly updated.
• Hangouts - Releases or calls for volunteers are often announced in our Hangouts group. Feel free to request an invite here.
• Blog - Screenshots and details of major releases are posted here.
• In-person and virtual meetups to foster our volunteer developer community - our app was represented at the Wikimedia Hackathon 2017 (and the associated pre-hackathon in Prague), the "Women in the Wikimedia movement - technical spaces" virtual meetup (2018), the Wikimedia Hackathon 2018, Wikimania 2018, and the Wiki Techstorm 2018. Plans are ongoing to include it in the Wikimedia Hackathon 2019.
• Mentorship - We mentored two GSoC students (Tanvi and Ujjwal) in projects related to our app in 2018, and hope to be able to mentor GSoC or Outreachy participants in 2019 as well.

Get involved

Participants

Please use this section to tell us more about who is working on this project. For each member of the team, please describe any project-related skills, experience, or other background you have that might help contribute to making this idea a success.

Grantees

• Josephine Lim - project lead (User: Misaochan, GitHub: misaochan). I have been the project maintainer of the Commons app since September 2016, and have worked on the app as an Android developer since October 2015.
• Neslihan Turan (User: Neslihan_Turan, GitHub: neslihanturan). Neslihan has been a regular code contributor to the Commons app since March 2017, and she joined our team as a UI designer & developer (Android) and assistant project manager in our last IEG grant (starting Nov 2017).
• Vivek Maskara (User: Maskaravivek, GitHub: maskaravivek). Vivek has been a regular code contributor to the Commons app since March 2017, and he joined our team as an Android developer in our last IEG grant (starting Nov 2017).
• Ashish Kumar (User: Ashishkumar468, GitHub: ashishkumar468). Ashish, the newest member of our team, has been a regular code contributor to the app since May 2018. He has worked on other projects as an Android developer since October 2015.

Advisors

• Nicolas Raoul (User: Syced, GitHub: nicolas-raoul). Nicolas has been a Wikimedia contributor since 2005 and was the previous project maintainer of the Commons app.
• Vojtěch Dostál (User: Vojtěch_Dostál). Vojtěch is the chair of Wikimedia Czech Republic and an avid user and supporter of the Commons app.
• Dmitry Brant (User: DBrant_(WMF) , GitHub: dbrant). Dmitry is a senior software engineer on the Wikipedia Android app team and a collaborator of the Commons app.
• Volunteer Have loved contributing to the Commons Android App since 2016, and hope to work on it more regularly this year! Thanks everyone for always being friendly (even when we make mistakes), and making the apps-android-commons repository so welcoming to new contributors. I've learnt so much and enjoy the time spent on the project :) Domdomegg (talk) 13:47, 24 December 2018 (UTC)

Community notification

You are responsible for notifying relevant communities of your proposal, so that they can help you! Depending on your project, notification may be most appropriate on a Village Pump, talk page, mailing list, etc.--> Please paste links below to where relevant communities have been notified of your proposal, and to any other relevant community discussions. Need notification tips?

• Mailing lists: wikitech-l, commons-l, mobile-l, wikivoyage-l
• Commons_talk:Mobile_app
• Commons:Village_pump
• Blog post
• Facebook group post

Endorsements

Do you think this project should be selected for a Project Grant? Please add your name and rationale for endorsing this project below! (Other constructive feedback is welcome on the discussion page).

• I strongly endorse this project proposal. Josephine is a great team leader and also a strategist. The quality of the proposals is improving year by year and this one is really well-thought - it reflects the most serious challenge the app has faced during the last year, i.e. code quality and bug predictability. Vojtěch Dostál (talk) 18:54, 27 November 2018 (UTC)
• Endorse. Saying that this app has potential is an understatement. Most young people don't have access to a computer in their spare time, so without this app Wikipedia articles on most topics will become more and more under-illustrated. Also, please keep in mind that Josephine and her team are dedicating a lot of their time to just maintain the app, fix existing bugs, reply to Play Store comments, etc, in addition to the grant content. Syced (talk) 02:59, 28 November 2018 (UTC)

1. I would like to endorse the project and thank the creators of the app. It has helped me immensely to contribute quickly and efficiently with illustrative encyclopedic content, despite of my multiple requests for help and bug reporting. The tool is super useful and needs support to become even better than it is now. Good luck! →Spiritia 17:49, 28 November 2018 (UTC)

• Strong endorsement - I love the Commons mobile app and its easy user interface. This grant/team will help maintain a pivotal app and help increase the content on Commons, as it is much quicker to upload an image on Commons via mobile. Additionally, I have seen the commitment of this team in fixing bugs and resolving issues quickly, leading to my conclusion that this team deserve the grant for continuing their great work of maintaining and building the Commons mobile app. Rogueassasin123
• Endorse. I do not use mobile myself, but live in a region where most people's only internet connection is by mobile. The application looks both useful and a worthwhile use of funds. · · · Peter (Southwood) ^(talk): 07:24, 29 November 2018 (UTC)
• While I endorse the improvement of this app, I strongly oppose the aim to detect faces or to suggest Commons only wants images of notable people. I also encourage the developers to look beyond documenting "places". See discussion page. -- Colin (talk) 10:27, 29 November 2018 (UTC)

• I just wanted to note that, after discussion, we have modified the relevant section of the proposal based on this feedback. Thanks for the suggestion re: detecting the front camera instead, Colin! Misaochan (talk) 10:21, 12 December 2018 (UTC)

• Endorse - I have a vested interest as I am a regular user of the app and would like to see these improvements coming. And so far the work they've delivered has been nothing less than stellar. Stephane (talk) 12:45, 29 November 2018 (UTC)
•  Strong support The future of the internet will be mobile{{refnec}}!. As a file uploader to Wikimedia Commons and a mobile user, I totally support and endorse this grant. Dyolf77 (talk) 17:19, 29 November 2018 (UTC)
•  Strong support I absolutely love the work done so far and this really needs to be continued. Localization, delayed upload and all the other features being considered will all add value and encourage greater participation. Shyamal (talk) 08:39, 30 November 2018 (UTC)
•  Support I've been using the Commons app this year for all my uploads, and I'd like to see the work on it being continued. Pmlineditor (t · c · l) 09:21, 1 December 2018 (UTC)
•  Strong support I would like to endorse this grant. It's good to see the detailed grant proposal. Some points:
  • It's good to see that you've learnt from the previous grant period and have tried to correct the mistakes.
  • Hope bugs don't sneak in like they did previously :-)
  • l like the upload pause/resume feature that has been suggested in the proposal. It would be useful in the place I live.
  • I would love to see the new main screen UI. I've sort of become bored seeing the existing UI for a long time. It could be improved and made elegant a lot.

Kaartic ^{correct me, if i'm wrong} 06:02, 2 December 2018 (UTC)

•  Strong support. Many new first generation internet users experience internet only through mobile. So we need strong position in the mobile apps segments. frequently update them. So I support this project very much. -- Balajijagadesh (talk) 07:13, 3 December 2018 (UTC)
•  Strong support Josephine and the team have shown excellent dedication and skill till now. In particular, I'd like to note the team's good and quick responses to the bug reports in the GitHub issue tracker. The plan is solid and detailed and all the goals make sense to me. --Amir E. Aharoni (talk) 09:30, 3 December 2018 (UTC)
•  Strong support Today a smartphone is the device most used to take a picture. It is therefore vital for Commons to have a robust mobile application to upload files directly for a phone. Yann (talk) 08:44, 4 December 2018 (UTC)
•  Support Señoritaleona (talk) 18:28, 5 December 2018 (UTC)
•  Strong support - Diptanshu 💬 12:39, 9 December 2018 (UTC)
•  Support Victuallers (talk) This needs to be used more, I try hard to use this. I think the stability targets are too modest. I suspect that stats would reveal that many users have installed this many times. (Because yes its great but it falls over). The app should also guess a title, description and category based on position and recent use. Filling in nearby places should also allow the option of loading from commons. I would like to tell non-wiki enthusiasts that this is a responsible choice for someone who wants to say take pictures of delegates at a conference. At the moment its too unreliable. We don't need a %age improvement, but 1 or 2 magnitudes. 1 failure in 10,000 would be acceptable. What is the tie in with wiki loves monuments? Surely they should be heir apparent to spread the good news? Victuallers (talk) 12:01, 12 December 2018 (UTC)

• Thanks for the feedback! Let us discuss your suggestions further here. :) Misaochan (talk) 12:19, 16 December 2018 (UTC)

• Mobile is the present and the future. We need to make the mobile app really easy and convenient for the Commonists. Satdeep Gill (talk) 03:10, 14 December 2018 (UTC)
•  Support Many people are accessing the internet only through mobile phones and photographing using them is also more and more common. Walter Klosse (talk) 12:03, 16 December 2018 (UTC)
•  Support the app needs to work. -- Ailura (talk) 10:59, 5 January 2019 (UTC)