Closed misaochan closed 4 years ago
The proposal looks very nice! :ok_hand: .
Limited connectivity mode would be a brilliant addition! Especially if we could imlement better caching for contributions, browse and nearby(If possible, this could work like Google Maps's offline maps feature)
video demonstrating a diverse range of participants talking about our app seems like a nice idea for better outreach. If the video will be produced after the summer of 2019, I might even be able to convince one of my close friends, an amateur video editor, into editing the videos. No promises though :D
Overhaul legacy upload code and UI will be a great addition both in terms of app usability and code maintainability. For some time I have been working on the UI portion of this overhaul and I expect the PR #1796 Upload UI overhaul to be complete much before March. Thus, work will only remain on the upload service and backend code. While the backend code requires a lot of work, would overhauling the backend alone take 20 person-weeks?
Hold workshops to teach people how to use the app to contribute to Commons is a great idea to gain new users, and I believe that the concept would benefit from getting more fleshed out. Maybe we could write up the descisions reached in #1871 into a wiki page to make it more permanent.
Thanks @ilgazer ! :)
If the video will be produced after the summer of 2019, I might even be able to convince one of my close friends, an amateur video editor, into editing the videos. No promises though :D
Awesome! Will let you know.
Thus, work will only remain on the upload service and backend code. While the backend code requires a lot of work, would overhauling the backend alone take 20 person-weeks?
I think it would be safer to allocate that much to it, especially as category search (we have 4 types of suggestions currently), adding templates for location/license/etc, all the file checks etc are included (and also very likely some other things that I hadn't thought of - I underestimated the time needed for tasks in the current grant). If you manage to do more than expected by then, we can always reallocate the time to, say, writing more unit tests or other improvements that weren't included in the grant. :)
I think it would be safer to allocate that much to it, especially as category search (we have 4 types of suggestions currently), adding templates for location/license/etc, all the file checks etc are included (and also very likely some other things that I hadn't thought of
I never looked at it that way. I can see how the code behind those functions would benefit from refactoring as well.
This looks excellent. Always happy to see that the app is in such good hands.
talk to the Wikipedia team
Better maybe say "talk to Wikipedia teams" as there are hundreds of Wikipedias each with a very specific culture? At the same time, I guess it is difficult to actually talk to all of them, if only because of the language barrier.
@dbrant Thanks so much! :)
@nicolas-raoul Ah sorry, I wasn't specific. I meant that we might want to talk to the WMF tech team behind the Wikipedia software that we decide to use for that purpose, to see if they think it is appropriate. So for instance if we reach a consensus that we would like to use the Wikipedia Android app, then we would talk to the Android team. If we decide on the mobile web version, we would talk to the mobile web team (I think there is a team for this)?
In the meantime I guess we can rope in @dbrant , haha. @dbrant , do you think it would be OK for us to call the Wikipedia app (via intent) for this purpose?
After uploading a photo via Nearby, if Wikipedia article exists for it and that article has no relevant images, allow user to add their recently-uploaded picture to the relevant Wikipedia article (or have a to-do list like Nicolas suggests). We would prompt the user to copy the image code (with filename and caption already prefilled), with brief instructions about where to put it, then load the relevant article via the Wikipedia app or Wikipedia mobile website. #872
@misaochan Did I tell you that you've become a fantastic project manager? :-) This looks really good and you must have put a lot of work into this. I like the way related issues are grouped together. It shows there is some thought behind all this.
Also I reaffirm my and my chapter's offer to help with app promotion next year as well. Now that social sites are growing, we can think about the in-person events (such as workshops mentioned in the text) or ways to address people at Wikimedia conferences.
@VojtechDostal Thanks so much! That means a lot to us. :) You guys have been a huge help in growing our userbase (BTW, the current active installs is 3887, I think we might possibly be able to hit 4000 by the end of the year :D )
@misaochan Great work at detailing out the plan for 2019. The tasks look good to me and more or less the estimates also look fine. :)
Update: I've just completed the on-wiki proposal - https://meta.wikimedia.org/wiki/Grants:Project/Commons_app/Commons_Android_app_v3 :) Would greatly appreciate if anyone could take a read through it, and provide feedback or endorse if you see fit. Also, if you are interested in officially signing up as a volunteer (not necessary in order to contribute, but would be nice), feel free to add yourself to the list of volunteers in the Probox (the template at the top of the page).
I will proceed with broader community notifications next week.
I've finally completed the first draft of the proposal for our Project Grant application! 🙂 If approved, we will start March 2019. Of course, I will need to flesh the proposal out some more before submitting it on-wiki, but I wanted to get everyone's thoughts before I proceed further. Ideally we could come to a consensus on which tasks we want to include in the proposal in 2 wks' time, so that I can start writing the on-wiki proposal then (would like to get it up by the end of Oct to get community feedback, and I will be travelling for 1.5 wks in Oct, so need to plan ahead a bit 🙂).
This project plan is based on person-week estimates for 3 part-time developers with feature loads (the 4th developer will be focusing primarily on bugs/crashes). The initial plan was to apply for a project lasting 9 months (the maximum length that a PG can involve is 12 months AFAIK). However, the number of estimated person-weeks below exceeds that significantly, and in fact is approximately equal to 12 months for 3 devs! So I guess we also have to decide whether we want to keep everything here and extend our plan to 12 months (if all of the grantees are OK with that), or whether we should remove some of the things and scale it down to 9 months. Also, if we want to add something new, we probably have to remove something else.
Feedback from anyone greatly appreciated! @neslihanturan @maskaravivek @ashishkumar468 @nicolas-raoul @VojtechDostal @whym @tobias47n9e @dbrant
Proposal draft
We want to focus on our strengths as a mobile app - (1) seamlessly guiding the user to upload photos for locations that need them via an interactive and fun process, and (2) a convenient and stable upload tool especially for people living in the global south, where Commons pictures are often lacking, and mobile phone usage and ownership greatly exceeds PC usage.
There are a few barriers that stand in the way of achieving this:
This grant aims to address these barriers.
Targeted acquisition of photos for places that need them:
Add filters to Nearby to allow users to filter for certain items. E.g. Nearby items that have Wikipedia articles, or types of items (instanceOf). Users have different preferences for photo trips, and may want to avoid (or specifically look for) historic buildings, parks, streets, etc. #1450 (8 wks)
Allow users to bookmark Nearby items that they plan to submit pictures for, and to view all their bookmarked items #1499 (8 wks)
After uploading a photo via Nearby, if Wikipedia article exists for it and that article has no relevant images, allow user to add their recently-uploaded picture to the relevant Wikipedia article (or have a to-do list like Nicolas suggests). We would prompt the user to copy the image code (with filename and caption already prefilled), with brief instructions about where to put it, then load the relevant article via the Wikipedia app or Wikipedia mobile website. (Note: if we go with the app, we should probably talk to the Wikipedia team about this first to ensure that they are OK with it) #872 (8 wks)
Fill P2096 (media legend) of P18 image using metadata typed by user. Insert image descriptions (or title? or both?) into Wikidata as qualifiers. This is quite often done using property P2096. Infoboxes could then read this description when transcluding images from Wikidata. #1831 (5 wks)
When user uploads a picture with geotag, check for Nearby items around that location, and if we find any nearby, ask user "Is this a picture of XYZ?" If they say yes, edit p18 property of that item. #259 (6 wks)
Track number of p18 edits made by user and include them in Achievements screen (5 wks)
Total: 40 wks
Increase diversity of Commons contributors:
Geographical diversity:
This will be useful to everyone, but especially for people in rural areas and/or the Global South where public wifi is rare and mobile data is limited and/or expensive. The aim is to allow these users to still use features like Nearby list (which uses little bandwidth) to take pictures on the go, but to hold off on high bandwidth operations until they are in a location with wifi.
Gender diversity:
Based on findings by WMDE in their "Charting Diversity" report (https://upload.wikimedia.org/wikipedia/commons/5/57/Charting_Diversity.pdf), key action points for improving diversity include (1) image and communication campaigns, and (2) informational/educational films. Quote: "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."
Total: 20 wks
Further reduce deletion rate & increase usability of images uploaded
Detect selfies (or more specifically, detect faces that constitute more than a certain % of the image) in uploads, and warn user that only pictures of notable people are allowed in Commons, if a face is detected. There are a few existing Android libraries for face detection, which we can attempt to reuse for our purpose with some modifications. After this prototype is completed, in the future we can consider increasing the strictness (e.g. only allowing uploads of faces by users with a reasonably low revert rate) depending on how reliable the library turns out to be. #74 (8 wks)
Polish feature that allows users to help patrol images uploaded via the app - the prototype was completed during Wikimedia Hackathon 2018, but some additions/changes are needed before we can release it to users. #1559 (8 wks)
Unlock features based on number of uploads and revert % #1869 (10 wks)
Allow users to modify or add categories/descriptions afterwards #161 (6 wks)
A to-do list for the user that contains: (1) images that they uploaded with no categories/descriptions (2) images that can be added to associated Wikipedia articles that have no pictures. The user should be able to filter their contributions list by 'action required' to show only these images. Even if the user doesn't filter, there should be an indicator (perhaps an icon on the bottom right of an image) for actions required. Maybe the 'W' icon for those that need to be added to Wikipedia articles, and a '!' icon for images with no categories/description #1870 (10 wks)
Total: 42 wks
Increase app stability, code quality and ease of uploading
Overhaul legacy upload code and UI. Our legacy upload backend and UI is still based on its original incarnation from 5 years ago - our volunteers @psh and @ilgazer have kindly paved the way with a few PRs to begin an overhaul. We will pick up wherever they leave off when the grant begins, and ensure that the entire upload process is completely modernized while maintaining feature parity with our current upload process (e.g. implementing zoom, tooltips, the various file checks, all our existing types of category search, etc), and finalize this overhaul. #1128 (20 wks) (Optional thought: If user has revert rate >50%, we could have a red text warning underneath the declaration and make them tick it manually every time?)
Reduce complexity. As mentioned by @dbrant, we have a high number of third-party components and libraries that are used in our app, thus increasing complexity and the potential for difficult-to-solve bugs and crashes down the road. He has kindly submitted PRs to remove some of the redundant dependencies, but we still have a ways to go. Having implemented a stricter process for including new libraries in our app, we will now go through all our existing dependencies to see if we should keep or remove them, and refactor the code accordingly. #1863 (10 wks)
Take a deeper look at our authentication system, which has been the culprit of several failed upload issues. Notably, 2FA logins still need ongoing checks for the OTP (@maskaravivek could you elaborate on this please?) (5 wks)
Further reduce bugs and crashes. With the new 4th member of our team focusing on bugs and crashes, we intend to reduce the number of open bug issues on our GitHub repo by at least 50%.
Write Javadocs for all classes in the "upload" package. Our eventual aim is to have full Javadocs for every class, but every little bit still makes it easier for new code contributors to get on board. (5 wks)
Test-driven development, test sheets, and automated testing?
Total: 40 wks (bugs/crashes not included as they will be assigned to 4th member of team)
New main screen UI
It seems a little bit premature to plan a newer UI when our new UI is still in development, but bear in mind that this "newer UI" will only be implemented at the end of the grant, which will be end of 2019 at the earliest. With the new features that we are planning (and some of the recent features that we already have, e.g. Achievements and Browse), it makes sense IMO to move away from My Contributions being the focal point of the main screen.
My (very preliminary) thoughts on a potential new main screen UI:
Bottom nav bar: Home, Nearby, Browse, My contributions.
Home (which will be the main activity) could contain:
Total: 15 wks
Finally:
Culminate in v3.0 at the end of the grant period.
Socialize project
After v3.0 is released:
Hold workshops to teach people how to use the app to contribute to Commons, with focus on either Global South locations, or female contributors. All travel will be local only and it is expected that people will bring their own Android mobile phones (which the majority of people in developing nations use), so costs will be kept low. Perhaps Vivek and Ashish can run one in India (if they agree), and perhaps I (Josephine) or Neslihan might run one for women. Or we will see if any volunteers are interested in running them. We anticipate the total cost for 2 workshops to not exceed USD 500. If this idea is successful, we will iterate on it in the future. #1871
Put up video showing a few people using Nearby to document the world around them as per "increasing diversity" section
Blog posts, mailing list posts, FB/Twitter posts, etc.
Total: 10 wks
Total number of person-wks for all the above: 168 wks
Metrics of success: