Grants talk:Project/Commons app/Commons Android app v3

Feedback from Harej

Thank you for submitting this proposal. I am happy to see that you are building off a record of success with the Commons app.

You write that one of the strengths of the app is guiding users to locations that haven't been photographed, but then you note that this feature isn't widely used. It may be worth trying to figure out why that is. Is it a flaw with the design of the feature, or are users just not that interested in it? If there isn't much interest I would recommend instead focusing on different features.

I would also like to know how your limited connectivity mode and outreach workshops will work, though I understand if you haven't completed those parts of the proposal yet.

Harej (WMF) (talk) 23:40, 20 November 2018 (UTC)

Hi Harej (WMF)! Thanks for your interest and feedback on our proposal. :) It is very much still in draft form and there are a few sections not yet written, but I will try to briefly touch on the points that you mentioned.

Re: guiding users to locations that haven't been photographed: It is indeed an interesting dichotomy, users have told us that they are very excited about the Nearby feature, but there are not as many p18 edits made via our app as we had hoped (which we track via recent Wikidata changes). Based on user feedback, some of the reasons that we have gleaned are:

• Sometimes p18 edits fail even though the image upload succeeds (so they actually used the feature, but the p18 edit didn't happen)
• Issues with the zoom and UI of the Nearby map
• Lack of quality-of-life features that would make photo trips easier with the app
• Not much motivation to make a lot of p18 edits as they cannot easily access a record of what p18 edits they have made

Some of the simpler reasons we are actively trying to address at the moment, but the ones that require more time will be added to this proposal. I will be writing up the project plan shortly, which will hopefully bring more clarity. :) I will also elaborate on the limited connectivity mode and workshops in the project plan.

Would you like me to ping you when the final proposal is ready for review? We would love to hear your thoughts on it.

Misaochan (talk) 09:12, 21 November 2018 (UTC)

Thank you for the quick response! A ping would be great once the proposal is ready. Cheers, Harej (WMF) (talk) 19:30, 21 November 2018 (UTC)

Hi Harej (WMF), thanks for offering to review the proposal! I've just completed the final draft. Community notifications have not started yet, but everything else should be in place. :) Misaochan (talk) 10:47, 23 November 2018 (UTC)

Misaochan, I just finished reading through the proposal, and it looks very good. Thank you! Harej (WMF) (talk) 19:38, 3 December 2018 (UTC)

Thanks Harej (WMF)! We really appreciate the feedback. :) Misaochan (talk) 10:07, 4 December 2018 (UTC)

App utilization and public communications

I am glad to see continued support for this app.

The current number of users, while significant, has potential to grow.

I encourage the project team to put additional emphasis on outreach and public communications regarding the app's availability and features, particularly to Wiki Loves Monuments organizers.

I would like to challenge the team to set a high but achievable target for number of active installs, higher than their draft target of 5000, perhaps 15,000, and to develop a somewhat detailed plan for how to reach that goal. There could be related high but achievable goals for other metrics in proportion to the increased goal for number of active installs. The team might want to consult with communications and marketing experts about how to develop that plan. There might be some costs involved for the consultation, developing, and testing of the plan. I would support some modest investment of time and money for these communications and marketing efforts. Execution of the plan might be in a separate grant depending on what plan the team develops and what resources the team thinks are needed to execute the plan successfully. Thanks, --Pine^✉ 22:57, 22 November 2018 (UTC)

Hi Pine, thanks for the suggestion! To be honest, I am a bit worried about doing anything that would increase the budget further, do you think it would be justifiable? I was afraid that the current budget might be a bit on the high side already, so I have been trying to reduce costs as much as possible. My thought was that we would build a solid technical and feature base first, and use the resources at our disposal to do what outreach we can. Consultations with marketing experts and paid marketing efforts would be a fantastic step forward, but I was thinking that that could be the focus of our next grant instead, to avoid adding further to the financial burden of this one... what do you think? Misaochan (talk) 10:23, 23 November 2018 (UTC)

Hi Misaochan, I understand the desire to minimize cost but there is also the question of value for money, and sometimes I think that spending more is the best choice. The current proposal requests $62,900, and my thinking is that if WMF is going to spend that amount of money, if your current users generally like the app and are making good use of it, if the user base has substantial room to grow, then I would be willing to support some additional money for marketing and communications in an attempt to maximize the impact of that $62,900.

I suggest that you request funds for developing a communications and marketing plan in this grant, but postpone requesting money to execute that new plan until the next grant, at which time you should know what resources to request for executing the plan.

In this round I suggest that you consider requesting approximately $4000 to develop the marketing and communications plan, both for your time and for the time of a marketing consultant. Assuming that you get a high quality consultant who bills at $150 per hour and you are billing at $25 per hour, $4000 would buy 20 hours of paid time for the marketing consultant plus 40 hours of your time for this planning work. I think that this could be money well spent and would prepare you to scale up your marketing and communications in your next grant when you request money to execute the new plan. --Pine^✉ 04:03, 24 November 2018 (UTC)

Hi Pine, that does make a lot of sense. Is there any guideline that the grants committee has re: choosing and hiring external consultants? Or perhaps it might be a good idea for me to put out a call to the community to see if there are any Wikimedians who specialize in marketing and who might be willing to join our team as a co-grantee for 20 hours? Misaochan (talk) 08:57, 24 November 2018 (UTC)

Also, I just realized that if we go with that plan, we may not see any additional increases in active installs at the end of this grant, because we would only have a marketing plan, with no execution. I wonder if it would be feasible instead to apply for a Rapid Grant for these marketing consultation fees after v3.0 is out? AFAIK Rapid Grants can be awarded quickly, so if it is approved, we can proceed with the consultation very soon after v3.0, and then use the results from that to create an execution plan for a future grant. That would also give us more time to research marketing consultants in order to get the best value for money (the current proposal unfortunately needs to be finalized by Nov 30, which does not give us much time). Misaochan (talk) 10:24, 24 November 2018 (UTC)

Hi Misaochan, I suggest that you wait to select a consultant until after the grant is approved. Although there are marketers of various types who participate on Wikimedia projects and you could reach out to them, I encourage you also to contact reputable marketing consultants in your area that you can meet in person and who have demonstrated experience with significantly increasing the user base of mobile apps. I am not aware of any policy reason that WMF would not fund a request for communications and marketing work, but I am pinging I JethroBT (WMF) here to verify that there are no blockers. I think that if WMF is going to spend $62,900 anyway then an additional $4,000 to develop a plan to maximize the impact of the product would likely be money well spent if you can find a high quality consultant who is a good fit for this project. --Pine^✉ 21:19, 24 November 2018 (UTC)

Hi Pine, thanks for pinging Jethro, and for the additional information - I was erroneously assuming that we needed to have picked a consultant before requesting the funds. If the grants committee or WMF gets back to us confirming that we are OK to go ahead with this change, I will modify the proposal as per our discussion. :) I will still need to proceed with the community notifications tomorrow because we are running out of time, but I think it should be OK to add this item after that depending on the results of this conversation. Thanks for taking the time to help! Misaochan (talk) 15:08, 26 November 2018 (UTC)

@Misaochan and Pine: Hi folks. Generally speaking, funds spent for communication or marketing of a project like this to encourage its use are eligible. Whether to include this or not is really up to your discretion, and I think you'll want to consider what your goals are for this project, how these activities around communication / marketing will fit in a larger timeline of work, and overall feasibility of being able to complete the work itself. In terms of the details of the communications / marketing work itself, it's generally better to have a person selected ahead of time, as with any role for a grant. However, if you can describe when this work would be needed and what sort of communications or marketing approaches might be needed, that should be sufficient information. If you have specific people or services you are considering around this work, that information would also be useful to know. Thanks, I JethroBT (WMF) (talk) 20:10, 26 November 2018 (UTC)

Hi I JethroBT (WMF), thanks for the clarification. In this case, there would not be any actual marketing "work" done per se, but rather a consultation to develop a plan for marketing work - i.e. the end result of that particular task would be a plan for future work. Is this something that WMF may consider, or is it generally recommended that any activities carried out in a grant should have standalone benefits?

Pine, I just talked to our advisors about your suggestion, and was advised by Syced that marketing a contribution-centric app is very different from marketing a normal Android app, so we would be in need of a very niche consultant (i.e. one who is familiar with open contribution apps) if we want to get a useful plan from them. I do agree with his viewpoint - IMO, the usual strategies that an app marketing consultant would employ would usually involve advertising the app in a manner of "how can this app make your life easier/more entertaining/better?", whereas our app is based around the philosophy of being a convenient tool to benefit the Wikimedia mission. What do you think? Misaochan (talk) 17:21, 27 November 2018 (UTC)

@Misaochan: While it is true that there can be good outcomes of projects that occur outside of the grant period, I think funding for consultation for planned that will not happen during the course of the grant period is likely to be problematic. The expectation is that the goals or planned work of a project can be completed within the limits of the grant period itself. In Project Grants, this period can be up to 12 months, so projects should be scoped accordingly. Funding for work that may (or may not) happen after the grant period is likely to be controversial, so I wouldn't recommend funding these activities if they can't be completed within the grant period itself. You could consider rescoping the project so there is time to implement these activities if they are integral to your project goals. I JethroBT (WMF) (talk) 17:31, 28 November 2018 (UTC)

@Misaochan and Pine: I was a bit sceptical when I first read about this suggestion from Pine, but the more I am thinking about it, the more it makes sense to me to talk to people who are knowledgable in the marketing area. However we should be careful there. Currently our use base is from the Wikimedia community. If the marketing strategy means outreach to non-Wikimedians, it might create new challenges. On the other hand, if the target group remains Wikimedians, I have serious doubts that people without knowledge of our community can come up with something really novel. --Vojtěch Dostál (talk) 18:42, 27 November 2018 (UTC)

• @Vojtěch Dostál, I JethroBT (WMF), and Misaochan: based on the above, here's what I suggest:

• Move the marketing and communications work to a separate grant. Request an initial Rapid Grant to do initial research and consultation and to find your preferred consultant, all which can hopefully be done for less than $2000. Based on that, you can decide what to do for next steps. I think that there will eventually be a use for more than $2000 for marketing and communications work and so eventually, perhaps 2 or 3 phases of marketing or communications in the future, you can include this type of work in a future Project Grant.
• I'm uncertain about the nature of the app being so different from most other apps that it would require a niche consultant, but I'd prefer to let you consider that during your initial work during the Rapid Grant. One possibility is increasing the gamification of the app to increase the mass market appeal, although that might require some feature development. There's a complex interplay of software development, software market research, and marketing of "finished" software that is in continuous development. All of these would be good subjects to research yourself and to discuss with potential consultants. You might also ask the WMF teams that support the Wikipedia apps for advice.
• I think that the target market should mostly be non-Wikimedians. Marketing to Wikimedians through known channels is, I think, relatively easy to do through established practices. While I would support some funding for marketing to existing Wikimedians through these existing channels, mainly I would like the consultant to advise on how to market the app to non-Wikimedians. --Pine^✉ 22:25, 28 November 2018 (UTC)

Gamification is a fantastic idea - I think it would be beneficial for Wikimedians and non-Wikimedians alike, really. :) I definitely also think there is merit in applying for a Rapid Grant after we release v3.0, to allow us to carry out dedicated research on marketing (with or without a consultant, which we can discuss further about). Misaochan (talk) 11:41, 29 November 2018 (UTC)

• Misaochan, in an interesting coincidence, the "Recent Research" report in the current issue of the Signpost mentions a study that suggests that gamification of Commons could be beneficial. --Pine^✉ 01:07, 3 December 2018 (UTC)

Thanks Pine! I had actually been in contact with Amanda previously, but had forgotten all about that. We will take a look at the study. :) Misaochan (talk) 10:09, 4 December 2018 (UTC)

Project Grant proposal submissions due 30 November!

Thanks for drafting your Project Grant proposal. As a reminder, proposals are due on November 30th by the end of the day in your local time. In order for this submission to be reviewed for eligibility, it must be formally proposed. When you have completed filling out the infobox and have fully responded to the questions on your draft, please change status=draft to status=proposed to formally submit your grant proposal. This can be found in the Probox template found on your grant proposal page. Importantly, proposals that are submitted after the deadline will not be eligible for review during this round. If you're having any difficulty or encounter any unexpected issues when changing the proposal status, please feel free to e-mail me at cschillingwikimedia.org or contact me on my talk page. Thanks, I JethroBT (WMF) (talk) 23:20, 27 November 2018 (UTC)

Selfies

The "selfie detection" idea was mentioned on Commons a while ago. As I noted then, I'm sure the vast majority of selfies can be eliminated by discouraging or preventing the use of the front camera. The front camera is often very inferior to the rear camera in terms of resolution, autofocus, sharpness, and often automatically combines filters that soften the photo to "improve" faces.

The proposal here is "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." This has several problems.

• Face detection will spot statues, toys and things that aren't actually faces, which will be annoying for the user.
• What % of the image is unacceptable?
• Commons has no notability policy on people whatsoever. I'm sure the community would reject that message in the strongest possible terms. The requirement on Commons is meeting an educational scope, not notability. Nor is it Commons mission to only illustrate Wikipedia articles. If one compares Commons repository vs images used on educational/factual/news one realises we have a very odd ratio of images of people vs images of nature/architecture/objects. There is a strong educational need for images of people, especially people doing something or people in certain roles due to their profession, hobby, beliefs, etc.

So I am very opposed to this feature, which is designed to eliminate people from our photos, and which is an over-engineered "solution" to a simple problem. People take selfies with the front camera. They do not generally take other photos with the front camera. -- Colin (talk) 10:23, 29 November 2018 (UTC)

Hi Colin, thanks for the feedback, we really appreciate your perspective. To clarify, there was never a plan to prevent face uploads entirely - we intended to start with a warning (e.g. "Please be aware that selfies are not acceptable") and perhaps later, to disallow uploads of faces from users with poor deletion history (so for instance if someone uploads a face but 80% of their previous uploads required deletion, there is a high possibility that the image is not useful). However, you are correct that false positives will be generated, and that this may be annoying to users. The % threshold and exact warning message can all be modified according to feedback.

The main problem with "discouraging or preventing the use of the front camera" is that this is not so simple in Android devices (whereas AFAIK it is trivial for iPhones). There is a huge range of different Android devices, different camera apps, and we cannot rely on the EXIF generated to tell us clearly "this was taken with the front camera". We have discussed this here in the past, however there would be a lot of guesswork involved, and we would literally have to create a database for every Android device on the market. IMO it will likely not be any simpler, and will also generate false positives. It is possible that we could just start with the few phones that do have front/back information in the EXIF, but that would leave out a lot of cases.

What do you think? If the Commons community themselves are against selfie detection entirely, we are OK with removing that task in the proposal too. The selfie detection task was based on feedback we have received from Commons users who are very concerned about people uploading selfies with a mobile uploader.

Misaochan (talk) 11:22, 29 November 2018 (UTC)

Don't try to solve 100% -- there's no point. Instead think smart and focus on the popular cameras. Have a look at Flickr Cameras. You can click on the mobile phone brands to get numbers for various models. iPhone is the majority camera now, though this is just the android app. You can see that Samsung's numbers are 5-10x those of Sony, LG, Moto, etc. So by coming up with a solution for the top 20 android phones, say, you'd probably reach 95% or more of all photos taken with an Android. Even if you had to resort to focal length & aperture to guess, a table of 20 items would be easy to implement. And if some brands (OnePlus?) name the camera used, then that might work for all models in that brand. Extracting sample photos from Commons per model and then examining the Exif with EXIFTOOL sounds relatively simple. A whole lot simpler than assuming the Android face recognition is going to help you -- is that API even available in all cameras -- or working out what percentage constitutes a selfie. -- Colin (talk) 12:18, 29 November 2018 (UTC)

Interesting suggestion. You're right, 95% would be more than sufficient. My main concern would be maintenance, as the "popular phones" change so quickly, but an update once a year would suffice methinks. I will ping the other developers on our GitHub issue to see what their opinions are. :) As for FaceDetector on Android, it is part of the Android SDK and would analyze the image itself, not the camera, so it is camera-agnostic and would be available on all Android phones. However, it is true that we may be throwing out the baby with the bathwater with our approach. Misaochan (talk) 14:10, 29 November 2018 (UTC)

Nearby places that need photos

As with the "only pictures of notable people are allowed in Commons" misconception, I am concerned the developers are focusing too much on documenting places. While we do have an imbalance with the global south and urban/rural, Commons is historically very strong at documenting places compared with documenting people or events. The Wiki Loves Monuments and Wiki Loves Earth competitions add to that strength. One advantage of a mobile phone is that it is nonthreatening compared to a DSLR when photographing people and events. Remember also that Commons does not just exist to illustrate Wikipedia articles. While an article on police officers, for example, may only require one or two photos of modern officers in uniform, there's no reason why Commons can't have photos of police officers from all countries, all ranks, all genders, all races, etc, etc. So please look beyond seeking the lead photo in a "place" article.

Thanks for the feedback. Surely places and people are not mutually exclusive - we can do both. :) We were focusing on places because there is already a very reliable framework that we can use (geolocated Wikidata items with no p18 image), and also because it inherently builds on the strengths of a mobile uploader. Could you suggest a feature we could implement that would encourage photography of people and events? Misaochan (talk) 11:27, 29 November 2018 (UTC)

Using the phone to take photos of food seems a popular activity, and if done well and categorised properly, could be a great way to improve world food images. Perhaps a rolling cycle of suggestions to prompt users? You could use the community to suggest ideas (much like Photo Challenge themes are chosen). Such as "Today, take a photo of your commute to work". -- Colin (talk) 12:00, 29 November 2018 (UTC)

This is a cool idea and ties in very well with Pine's suggestion of gamification above. I posted on an issue about it. :) Misaochan (talk) 15:31, 29 November 2018 (UTC)

Photo Challenge

Here's a suggestion perhaps for the future. Add the monthly Photo Challenge to the app. A notification could alert to the new challenge. The app could help automatically upload images to Commons and insert them into the challenge page. It could even help with voting. -- Colin (talk) 10:36, 29 November 2018 (UTC)

Great idea! Do you know if there is an API that we can use for this? Misaochan (talk) 11:27, 29 November 2018 (UTC)

Sadly no, other than standard wiki editing. The submission and voting pages do follow a fixed pattern so automating should be relatively achievable. I've been trying to recruit some Javascript help to improve the Web UI on those pages but so far no volunteers. -- Colin (talk) 11:55, 29 November 2018 (UTC)

Two feature requests

I have two additional features to request which could probably make use of the storage and batch processing infrastructure of https://tools.wmflabs.org/video2commons/ - this would allow the uploading of videos and audios - whose formats are difficult to manage otherwise. Shyamal (talk) 08:44, 30 November 2018 (UTC)

Hi Shyamal, thanks for the suggestion! Just to be clear, the additional features you are requesting are video and audio uploads via the app, using the batch processing tool that you linked? Misaochan (talk) 10:04, 30 November 2018 (UTC)

Yes. Shyamal (talk) 10:07, 30 November 2018 (UTC)

I have posted your request on our issue, will keep you updated. :) Misaochan (talk) 10:27, 30 November 2018 (UTC)

A few comments/questions

Thank you for your tireless work. I can not unfortunately test this app as I possess only iOS devices. Still I have few comments:

1. "Buggy pull requests by well-meaning new volunteers ... " I do not understand why you have not restricted the write access only to the members of the project team?
2. The "Part 3: Increase diversity of Commons contributors" in part related to gender diversity looks superfluous, in my opinion. You have no plan to do anything in this direction that will make a practical impact. In fact, you can not realistically do anything. Creating just a video, which nobody will watch, is just unnecessary distraction from your main work. I suggest that you drop it. On the other hand the part related to the geographical diversity should be kept as you can do something that may be really useful.
3. It may be a good idea to consider adding a banner to the Commons mobile page advertising the app. I quite often see such banners on many sites advertising their mobile apps. Although such banners may be annoying in some cases.
4. Which versions of Android will the v3.0 support? What will be the minimal requirements?
5. Are you planning to support other Android devices like tablets?

Ruslik (talk) 18:40, 7 December 2018 (UTC)

Hi Ruslik, thanks for taking the time to review our proposal!

1. Sorry, I didn't word that very clearly. Yes, only people with collaborator permissions and above (i.e. members of the project team and volunteers who have been around for a long time) have write access to our repository. All code is submitted via pull requests, which a person with write access will then merge after manual testing. However, we don't usually have the time to test the entire app with multiple use cases for every single pull request. We will usually just test the most common use cases of the specific part of the app that was the focus of the pull request, saving the more thorough testing for releases. This means that sometimes, the pull requests have side effects on other parts of the app, or behave differently on different use cases, that we don't realize until later (usually when the app has gone into beta testing). So that is a key reason for our proposed code quality improvements, especially unit tests. More modular code will decrease the risk of side effects, and unit tests (which run automatically every time a pull request is submitted) will give us advance warning of problems in other areas of the app if the pull request fails those tests.
2. Hmm. One of the places we intend to put the video up on is our Play Store page, which most new users will see before they decide whether to install the app or not. Sometimes users do watch the video before they decide, if the page has a video. Of course, if the committee decides that the video should not be made, then we can do without. But I was hoping that we could at least try - the amount of time needed to make the video is only a small fraction of the time needed for the whole project, so there is very little risk IMO, and even a small impact would be worth it.
3. This would be fantastic if possible! :) We are currently on the sidebar of mobile Commons (you can see our links if you are logged in and you expand the sidebar). But a banner on the main section of the page would be great if we are allowed to do so.
4. It is difficult to name specific versions 1+ year in advance, as we do not know the timeline and content of Google's Android updates that far in advance. However, our app currently has a minimum Android SDK version of 15 (Ice Cream Sandwich), which, according to the Android distribution dashboard, means that it supports 99.8% of Android devices. In v3.0 we intend to maintain this percentage. It does involve some hassle to support such a wide range of Android versions, but it is really important to us that the app be usable across a wide variety of devices so that people on the lower end of the phone market are not excluded.
5. Yes, the app already supports tablets, and will continue to do so. I usually just say "phones" when talking about the app, since most of our users are phone users - probably because it is rather uncommon for people to take photos with their tablet. :) But it can certainly still be used on a tablet if the user wishes - this is what the main screen of v2.9 beta looks like on a tablet, for instance. The only other Android devices on the market are Android Wear (smart watches) and Android TV. We do not currently support those and do not really plan to in the near future, as they are not suitable for taking pictures with - one of the main conveniences of our app is that it can be used on the same device that was used to take the picture. But if the tech changes in the future, we could consider it.

Misaochan (talk) 11:37, 8 December 2018 (UTC)

Thanks, and the last two questions.

1. Does this app support login using 2FA?
2. Do you have a statistics, which versions of Android are used with this app?

Ruslik (talk) 08:24, 9 December 2018 (UTC)

Hello Ruslik,

1. Yes, 2FA logins are currently supported. However, as mentioned in the proposal, we occasionally get reports of failed uploads. We cannot be certain, but this issue appears to be more common in 2FA accounts. We would need to take a deeper look at our authentication system to weed out these sporadic issues.
2. Yes, we do! I posted a graph of the 6 most common versions here. Unfortunately the dev console only lets us view 6 at a time, but let me know if you'd like to see the less common ones as well, and I can take them stage by stage.

Misaochan (talk) 10:11, 12 December 2018 (UTC)

I think that in the future the development of the Commons app should be supported by WMF on a permanent basis. Applying for a project grant every year is not a sustainable way to continue the development work. Ruslik (talk) 19:52, 8 January 2019 (UTC)

Eligibility confirmed, round 2 2018

This Project Grants proposal is under review!

We've confirmed your proposal is eligible for round 2 2018 review. Please feel free to ask questions and make changes to this proposal as discussions continue during the community comments period, through January 2, 2019.

The Project Grant committee's formal review for round 2 2018 will occur January 3-January 28, 2019. Grantees will be announced March 1, 2018. See the schedule for more details.

Questions? Contact us.

--I JethroBT (WMF) (talk) 03:15, 8 December 2018 (UTC)

Feedback from Victuallers

Hi Victuallers,

Thanks for your feedback - I took the liberty of creating this topic to discuss it. :) And my apologies for the lack of app stability - we are genuinely trying to do better in that regard.

Goals/upload failures

We do actually hope for a multi-fold decrease in upload failures once we are able to overhaul the legacy code and take a deeper look at our authentication system. I did contemplate adding "decrease in upload failures" as a goal, but the main problem is that I can't figure out how to reliably measure this. The main hurdle around setting a specific number for upload failures is that we do not track user actions within the app, aside from publicly-available ones (like the list of user's contributions on Commons). As failures do not result in an edit, they are not publicly-available. So we are not actually notified about failed uploads unless users tell us, or they choose to manually send us their logs. To be honest I am not sure that we should change this, as there may be privacy implications.

I can think of two possible ways that we can still measure upload failures without any privacy concerns, but each will have significant drawbacks.

1. We poll users. Getting a statistically-significant sample size would take a lot of man-hours though, and the results would be skewed depending on which users choose to respond. Additionally, sometimes (not always) uploads fail for reasons beyond our control, and users don't realize this (for instance, if someone's account was blocked and they didn't read the message).
2. We run a script to upload images in various conditions, and analyze the results. This has the obvious drawback of needing to be run on Commons Beta, to avoid spamming the real Commons - again, this will affect the results. Also, we cannot possibly reproduce all scenarios that could lead to failures.

If anyone could suggest a way around these issues, I would be very happy to add this as a goal.

Other suggestions

• "The app should also guess a title, description and category based on position and recent use. " <- We do already suggest categories based on position (and recent use, too!), but titles and descriptions are a bit harder because they are so specific. Could you recommend a way that we could do this without inundating the user with a large number of possibly-not-useful suggestions?
• "Filling in nearby places should also allow the option of loading from commons. " <- I am intrigued. Could you elaborate further on this, please?
• "What is the tie in with wiki loves monuments?" <- At the moment, we do not have campaign integration yet. We are trying to start by displaying news about campaigns, but even with that, it has been difficult to find a suitable upstream API that we can use, with the start and end dates that we need (and as a result we needed to create our own file with start and end dates in order to do this). We are definitely hoping to make more progress on this in the future.

Best regards, Misaochan (talk) 12:17, 16 December 2018 (UTC)

• I'm not up to date with the privacy concerns. My only thought is to measure the number of installs. I think I've installed it 15 or 20 times. You could even have a reinstall button which would be totally unnecessary if the software is stable. Other possibility. You know how many images were loaded by X and how many they loaded via your app. A query of a large number of users would tell you if in general users were moving towards or away from the app. A sign of success would be to see this chosen as the software of choice by wiki loves monuments next year.
• Guessing more - (if you load a file then the file name should be included as the basis of a description. The app is in about the same geo place then the desc be the same as last time with ("looking North" added if different). I think you could make even better choices if you got the user to choose the categories first.
• Loading from commons - by this I am looking from a wikidata perspective. So I have identified a building that is a wiki item but it lacks a picture. Options are a)take a picture b) find one on my phone, disc etc and c! find one on commons and tag it correctly for the wiki data item. This would make the app wikidata centric and its aim would be to create a wikidata image and only if necessary to add an extra image. The app in this mode could be used to just find missing images for wikidata items. Users like MManske have software that does this but with no camera/disc/tag option. (Imagine - You go to take a picture of the Eiffel Tower and the app offers existing images instead and asks you to tag them better).
• Wiki loves monuments have a very similar app to yours which I assumed was the same app. Big pity if you are not serving their needs and spending their money too. Victuallers (talk) 14:31, 16 December 2018 (UTC)

Flutter framework

Have you considered flutter framework which allows to create Android/iPhone/web/future Google OS compatible apps? That would be a major rewrite project while using a new language, though. --Papuass (talk) 15:36, 2 January 2019 (UTC)

Hello Papuass, thanks for the suggestion. :) We have considered the use of a cross-platform framework like Flutter before, yes, but these frameworks have quite a few disadvantages that make us hesitant to do so. Regarding Flutter in particular:

• As you mention, it will require a complete rewrite. It will likely take more time/resources to re-implement an exact replica of the current app in Flutter than this entire grant will take, especially as all the developers would need to learn a new framework and a new language (Dart).
• Lack of third-party libraries is a big issue. We use a significant number of reputable third-party Android libraries so as to reduce development costs and not reinvent the wheel. As the Flutter ecosystem is relatively new, finding a suitable substitute for all of these libraries would be a challenge. We would also not be able to reuse the networking library that the Wikipedia Android team is working on, if we transition to Flutter. Additionally, we use continuous integration tools like Travis to run automated tasks on our GitHub repository, like running unit tests for pull requests, and automating alpha releases. AFAIK, there is not a similar substitute for Flutter at the moment.
• Flutter apps have larger APK sizes, which would be disadvantageous to people with older phones that have minimal storage space.
• Flutter is not exactly "build once run everywhere", even though some code can be shared between different device types. For instance, Cartune's developer estimates that only 50-80% of the code will be shared between Android and iOS implementations, with the remaining code having to be implemented on the platform side. They also mentioned that stability-wise, native development has the advantage.

Hope this helps. :) Misaochan (talk) 15:44, 3 January 2019 (UTC)

Number of issues

Hi and thanks for this very clear and well done grant proposition. I see that you currently have around 400 open issues on github. A reduction of 30% in one year means that you will have aroud 330 open issues at the beginning of 2020, which is still a lot. (I know you will not only have to solve 80 issues, but 80 issues + all the new ones that 2019 will bring). What would it take to, say, fall back to 50 issues, and why did you choose to not have such an ambitious target ? Léna (talk) 23:05, 12 January 2019 (UTC)

Thanks for the question. Misaochan has told us that she is traveling from 10th to 23rd January with unstable internet access, she will get back to you as soon as she is able? Maskaravivek (talk) 7:00, 13 January 2019 (UTC)

Hello Léna,

Misaochan here, thanks for your feedback! I hope you don't mind me responding with my non-2FA account, as I am traveling at the moment and unfortunately left my 2FA device at home, so I am unable to log in to my main (2FA) account until I return.

Re: open issues, I'd like to clarify that the metric in the proposal was "Open bug issues on GitHub reduced by 30%". We use GitHub issues not just for bug tracking, but also for suggestions of enhancements, including potential improvements for the far future, or discussion topics that the community has not reached a consensus on yet. As such, we do not intend to target a reduction of all issues, but only bug issues. You would be able to see those by filtering for the "bug" label, as seen here. We should probably have made this clearer in the proposal, sorry about that!

So, at the moment we currently have 67 open bug isues and 260 closed bug issues. (It is probably a bit more than that, since some of the issues are missing labels, but certainly not 400. We will go through all the issues at the start of the grant and assign labels appropriately, before we begin.) Let us go with that number for now - a reduction of 30% in open bug issues would result in a final number of 47 bug issues. As you say, this would also mean keeping a clean bug slate for 2019, which would be quite a feat in itself IMO.

It is difficult to set a more ambitious target than this because by nature, some bug issues are not fully in our power to resolve. E.g. sometimes we need more information but the user doesn't get back to us, or sometimes the issue lies with the upstream API etc. In those cases we usually still leave the issue open while waiting for the information to come in, at least for a reasonable amount of time.

Best,

Misaochan2 (talk) 15:13, 14 January 2019 (UTC)

Aggregated feedback from the committee for Commons app/Commons Android app v3

Scoring rubric	Score
(A) Impact potential Does it have the potential to increase gender diversity in Wikimedia projects, either in terms of content, contributors, or both? Does it have the potential for online impact? Can it be sustained, scaled, or adapted elsewhere after the grant ends?	9.3
(B) Community engagement Does it have a specific target community and plan to engage it often? Does it have community support?	9.5
(C) Ability to execute Can the scope be accomplished in the proposed timeframe? Is the budget realistic/efficient ? Do the participants have the necessary skills/experience?	9.0
(D) Measures of success Are there both quantitative and qualitative measures of success? Are they realistic? Can they be measured?	9.3
Additional comments from the Committee: The Commons app is a useful way to gather new users into Wikimedia projects. The app has a lot of improvement from the first versions and it has some WMF support. It seems well aligned with Wikimedia strategic goals, but I don't see how this project could continue after implements new functionalities. I knew of this app but just installed it after reading the proposal. I'm impressed by what is there and looking forward to these improvements. I think that this project is having and will have in the future a tremendous impact on the Wikimedia movement. It perfectly aligns with Wikimedia's strategic priorities. However its sustainability is still in question as without a secure stream of funding the app will eventually become obsolete. I see a lot of new ideas, realistic goals and well defined metrics to be measured. One of the metrics doesn't depends on the team, but I think is reasonable that the team could fail on it, because it depends on external factor (Commons admins, app users) The approach is iterative, the risks are low, the success can be reliably measured. The team is well formed and they are working from a few years ago in the app. The advisor people seems reasonable and they will improve the workflow and reduce the time to implement the new functions. I'm a little worried about the need to rewrite a lot of it, but I'm encouraged that they actually have experience with the old code and know where it needs to be improved. The team have without a question the necessary skills/experience to execute the grant, which is attested by their past development work on this app. I see a lot of support and interest from the community. I recommend a way to take the feedback from this presentation and put on any place to track it: veteran users and new users could bring new ideas -or new problems- and it will be a great way to generate a positive feedback from the community. (ps: github isn't the more friendly way to reach new ideas) I would like to see some on-wiki efforts as well (though, these may already exist and they just didn't mention them.) I haven't seen the use of the app discussed too much on-wiki and I see that there are several places near me that need pictures. The community engagement is sufficient for this project. Experienced people with a well written proposal to fund continued work on an existing app. I support this project as continuing the development of the Commons app is important, in my opinion. However I have rather a strong opinion that such kinds of projects should be funded by WMF on permanent basis.

This proposal has been recommended for due diligence review.

The Project Grants Committee has conducted a preliminary assessment of your proposal and recommended it for due diligence review. This means that a majority of the committee reviewers favorably assessed this proposal and have requested further investigation by Wikimedia Foundation staff.

Next steps:

1. Aggregated committee comments from the committee are posted above. Note that these comments may vary, or even contradict each other, since they reflect the conclusions of multiple individual committee members who independently reviewed this proposal. We recommend that you review all the feedback and post any responses, clarifications or questions on this talk page.
2. Following due diligence review, a final funding decision will be announced on March 1st, 2019.

Questions? Contact us.

I JethroBT (WMF) (talk) 16:21, 6 February 2019 (UTC)

Response to committee feedback

Huge thanks to the committee for the very encouraging feedback! :) We really appreciate it.

Addressing a few of the points made:

Permanent funding:

We would love that, if possible! To be clear, I think we can still do a lot of good with this grant, as the improved version of the app would remain on the Play Store after the end of the grant, as will all of the photos contributed via the app (along with the associated articles improved). We also have a sizable and active community of volunteer developers - they do not usually undertake large enhancements like the ones mentioned in the grant, but they do sometimes implement small enhancements and fix issues with the app, which helps with maintenance (all of the grantees were also volunteers at some point, and we have successfully kept the app afloat through previous periods of no funding). In the very unlikely event that the app is completely unmaintained after the grant, if it is stable and reasonably future-proof (which is one of this grant's goals), it should still be able to coast along for quite some time with no maintenance.

But, I definitely agree that stable funding would be ideal, if the app is to continue to grow after this grant is over (as opposed to just staying afloat). Permanent funding would also open up some fantastic new avenues to us. For instance, we would be able to devise longer-term strategies, and we could also put into practice any short term plans and make changes to those plans based on user feedback much more quickly, without having to wait for existing grant completion and the extra 3+ months that it takes for a new grant proposal to be written and assessed.

If we could get pointers on how (or to whom) we could request a more stable or permanent stream of funding, that would be wonderful and I would be more than happy to pursue it in the future.

On-wiki promotion of the app:

We would greatly appreciate suggestions on how we can improve our on-wiki promotion. :) We currently have a banner in the sidebar of the main Commons page when viewed via a mobile browser (visible only to logged-in users), a project page on Commons, and we often post about app updates in Tech News or on the Commons Village Pump (we restrict those to major updates though, so that we don't create spam).

Page for suggestions/feedback:

Aside from GitHub, we have a Google groups forum and a talk page on Commons for suggestions. I definitely think we can do better with a centralized page though, which one would you recommend?

Best, Misaochan (talk) 09:34, 18 February 2019 (UTC)

Round 2 2018 decision

Congratulations! Your proposal has been selected for a Project Grant.

The committee has recommended this proposal and WMF has approved funding for the full amount of your request, 62,900 USD

Comments regarding this decision:
The committee is pleased to support further development of the Commons Android app, and are especially supportive of the team’s efforts to focus on the needs of users in underserved communities where mobile phone usage greatly exceeds PC usage.

Next steps:

1. You will be contacted to sign a grant agreement and setup a monthly check-in schedule.
2. Review the information for grantees.
3. Use the new buttons on your original proposal to create your project pages.
4. Start work on your project!

Upcoming changes to Wikimedia Foundation Grants

Over the last year, the Wikimedia Foundation has been undergoing a community consultation process to launch a new grants strategy. Our proposed programs are posted on Meta here: Grants Strategy Relaunch 2020-2021. If you have suggestions about how we can improve our programs in the future, you can find information about how to give feedback here: Get involved. We are also currently seeking candidates to serve on regional grants committees and we'd appreciate it if you could help us spread the word to strong candidates--you can find out more here. We will launch our new programs in July 2021. If you are interested in submitting future proposals for funding, stay tuned to learn more about our future programs.

On behalf of the Project Grants Committee, KCVelaga (talk) 05:05, 1 March 2019 (UTC)