-
Notifications
You must be signed in to change notification settings - Fork 1.3k
IEG renewal proposal #694
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I think preparing for structured data on Commons could also be part of the proposal: http://structured-commons.wmflabs.org/wiki/File:LighthouseinDublin.jpg and https://commons.m.wikimedia.org/wiki/Special:MyLanguage/Commons:Structured_data |
@tobias47n9e good point. Do you know when structured data will actually be live? |
I guess the legacy API will be kept as a transition for a long time,
though? (I could be wrong)
So, probably 2 years before Commons switches to structured data, and like 3
years of legacy, so I would personally feel that the priority is not that
high compared to other features that would bring immediately visible
improvements in terms of incoming data/metadata content :-)
…On Wed, May 31, 2017 at 7:07 PM, Josephine Lim ***@***.***> wrote:
@tobias47n9e <https://github.com/tobias47n9e> good point. Do you know
when structured data will actually be live?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#694 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGFBq5H1BB8wOIagolirkrSi7D_Z84Mks5r_Tv-gaJpZM4NosVZ>
.
|
Okay, I think I've finished a (very) rough draft of the tasks. I think structured data could be left for next round in this case, plenty of time left :) Would appreciate any comments, both on the tasks themselves and of their feasibility, as well as additional ones that might be good to include. We are assuming 6 months of a total of 40-60 hours per week (split between 3 people). @nicolas-raoul @VojtechDostal @tobias47n9e @neslihanturan @maskaravivek |
Code quality in general might be another point. Currently Android Studio points out many classes as unsafe, which might be the reason behind some of the more obscure crashes. Clean code also means more people eager to contribute. Maybe also set a goal for test coverage. |
Jordan Adler @jmadler (from Google) sent me this email with feedback and suggestions for our app, and I'm posting them here with his permission. :) It's a little bit old, so we've done a few of them already, but I think the ones we haven't done could be considered for the renewal.
|
> I think there's some opportunity to gamify contributions here, focusing
around impact and usage. If you haven't already, I'd suggest joining and
experiencing the Google Maps Local Contributor Program. I think something
similar for Wikipedia/Wikimedia Commons could be helpful. Consider an email
or push notification letting me know that my contribution was a featured
image, used in an article, or hit a threshold of views. That'd definitely
make me feel like my effort was worthwhile, and encourage me to contribute
more.
I think this new feature would be awesome, and it is very fun to design and
implement such thing. On the other hand, such big feature needs to be
designed very carefully , it needs to be able to be enlarged. Thus, I think
we should add this to our future goals but we should start working on it
after we are done with everything else.
|
Minor remark, I don't think you can get an image's number of views. Anyone please prove me wrong :-) |
It seems that one of the IEGs was renewed for 8 months: https://meta.wikimedia.org/wiki/Grants:IEG/A_graphical_and_interactive_etymology_dictionary_based_on_Wiktionary/Renewal So it seems like we aren't limited to 6 months renewal after all. Although, it's debatable whether a longer renewal would be beneficial or desired? |
Benefits of longer renewal period (9 or 12 months instead of 6):
Disadvantages of longer renewal period:
What do you guys think? @VojtechDostal @nicolas-raoul @maskaravivek @neslihanturan |
Difficult decision indeed! It greatly depends on your medium-term life plans, so I don't have much advice to bring. |
I think we shouldn't set it to 12 months eventually. However 8 or 9 month seems legit to me. I personally guarantee that I will be working on the tasks at least until the time finished. I can arrange my other stuffs accordingly. |
@neslihanturan Yeah I think 6 months will be enough for all the tasks that aren't marked 'unsure' (bear in mind that the time needed is not just for development, but also for testing, getting user feedback and fixing any issues with implementations - from my experience this took a lot of my time during the previous grant). There are also a couple more important tasks that I haven't added to the top post, will do so shortly. The main issue here, I guess, is that of "what next?". Every grant can have only one renewal (AFAIK), so after the renewal is over, if work is to continue on this app, either we have to apply for a new Project Grant, or (and this is a VERY long shot, but a pipe dream of mine :) ) for a Simple Annual Plan Grant. Regardless of what decision we make, we should ensure that we are able to make enough of an impact with the renewal that we can be considered again for those. (Of course, there is no obligation for anyone to stay with us after the renewal concludes, if they decide not to). |
I agree that a 6-month grant is a good compromise between sufficient duration on one hand and flexibility on the other. As for Project grants/Simple APG, these tend to be accompanied by a certain amount of administrative work. Because Wikimedia Czech Republic already runs APG grants and is already involved in Wikimedia Commons App, why don't we rather include the budget for 2018 in the WMCZ's APG? Seems like the most reasonable solution to me. I will have to make some inquiries about ways to pay foreign nationals but I think Wikimedia Czech Republic can easily use services like Upwork: https://www.upwork.com/i/how-it-works/client/ What do you think? |
Budget from WMCZ could give us time to consider some long-term options. For easy access to WMF grants, maybe we should consider forming a Wikimedia Commons App Usergroup in 2018: |
@VojtechDostal That would be great if possible! (And less administrative overhead is always a bonus as far as I'm concerned :) ). I'm unfamiliar with Czech Republic laws on employment, but if you are allowed to pay contractors/grantees (and this doesn't conflict with your agreement with WMF) then that sounds like a good plan. I'm not sure how the timelines will merge, since you mentioned that the WMCZ grant starts in September? Or is the application in September and the actual grant period starts January? Will look into forming the usergroup, thanks. :) |
The WMCZ grant is going to be Jan-Dec '18. We don't need to be too specific about what we want to do with these money in the proposal. APG does not require such amount of details the way IEG does. Basically we'd have to have an overall idea of what the structure of the team will be and where we generally want to be in December '18 :-) |
Nice! :) Let us go with 6 months then. I have revised the opening post accordingly and will be going off of that when I write the renewal proposal (next week hopefully!). In order to make sure that the core tasks are finished, I think we might have to keep the [Not included] tasks for the following round. I have included rough estimates of the time needed for each of the above components - please let me know what you guys think. |
Yes, the goals we are setting look achievable to me in 6 months if all of us give our best. :) Am just not very sure about the notifications bit. It might be tricky as we would need some sort of a webservice that pushes these notifications to the subscribed mobile devices. |
@maskaravivek I agree, we probably need to look further into the push notifications. I wonder if it might be a good idea to just display in-app notifications for now (basically, just displaying the nearest Nearby place in the UI of the main screen), and save push notifications for later? Push notifications would be wonderful but we would likely need at least an idea of how we want to implement the server side code before we promise it to users. (It would be REALLY nice to have, though, I'm just not sure how difficult the server-side would be) |
An incomplete draft of the renewal proposal is now being worked on at https://meta.wikimedia.org/wiki/Grants:Project/Improve_%27Upload_to_Commons%27_Android_App/Renewal . Please feel free to browse and offer suggestions/feedback on the existing sections if you would like. As an additional measure of success, I wonder if we should include 'user feedback' as a measure, since many of the improvements in the renewal are aimed at improving the user experience and convenience. We could have a one-time survey (advertised in mailing lists perhaps) at the end of the grant period, and ask questions about whether the user feels that the experience has improved for them over the last 6 months, or how easy they find it to upload photos to Commons, etc, maybe on a scale of 1-10, with 7+ being the measure of success. It is quite a subjective measure though, so I am unsure about it. |
For user feedback, a good measure can be the number of stars given on
Google Play.
…On Tue, Jul 11, 2017 at 7:50 PM, Josephine Lim ***@***.***> wrote:
An incomplete draft of the renewal proposal is now being worked on at
https://meta.wikimedia.org/wiki/Grants:Project/Improve_%
27Upload_to_Commons%27_Android_App/Renewal . Please feel free to browse
and offer suggestions/feedback on the existing sections if you would like.
As an additional measure of success, I wonder if we should include 'user
feedback' as a measure, since many of the improvements in the renewal are
aimed at improving the user experience and convenience. We could have a
one-time survey (advertised in mailing lists perhaps) at the end of the
grant period, and ask questions about whether the user feels that the
experience has improved for them over the last 6 months, or how often they
use the app to upload photos to Commons, etc. It is quite a subjective
measure though, so I am unsure about it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#694 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGFBqfUDoECblRye5lSunPy4rLTlk6kks5sM1OCgaJpZM4NosVZ>
.
|
@nicolas-raoul Hmm. I am hesitant to use Google Play reviews because I think some of them aren't relevant, honestly. There are quite a few 1-star reviews by people who either (1) have a bone to pick with WMF and are taking it out on us, like the guy who was complaining about English Wikipedia, or (2) don't know what the purpose of the app is, like those who are complaining that it doesn't have Photoshop functionality. I was hoping that using a survey sent via mailing lists would at least ensure that the responders are those who are reasonably familiar with our app and Wikimedia projects, which is the target of most of our improvements. Do you think user feedback in general is a good metric of success though? |
Indeed Google Play review can be pretty tough and random. And people tend
to rate the whole initiative rather than the app itself, for instance
people who get a stinky room with Airbnb might give the app one star, even
if the app was flawless.
But I am not sure how many people would respond on the mailing list, which
does not have many readers I believe.
A link shown to experienced users within the app (once between date and
date+1month) could be an idea, if easy to implement.
…On Thu, Jul 13, 2017 at 1:53 AM, Josephine Lim ***@***.***> wrote:
@nicolas-raoul <https://github.com/nicolas-raoul> Hmm. I am hesitant to
use Google Play reviews because I think some of them aren't relevant,
honestly. There are quite a few 1-star reviews by people who either (1)
have a bone to pick with WMF and are taking it out on us, like the guy who
was complaining about English Wikipedia, or (2) don't know what the purpose
of the app is, like those who are complaining that it doesn't have
Photoshop functionality. I was hoping that using a survey sent via mailing
lists would at least ensure that the responders are those who are
reasonably familiar with our app and Wikimedia projects, which is the
target of most of our improvements.
Do you think user feedback in general is a good metric of success though?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#694 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGFBuJL8BHB-Lc6MeVSGuWTlFxNdjT4ks5sNPodgaJpZM4NosVZ>
.
|
Ah, good point. The link within the app sounds like a good plan to me, if feasible. Perhaps I will add it as an 'optional' measure of success, same as how I did with the 10+ new contributors the last time. |
Also, I wonder if there is a method for measuring test coverage just for the upload functionality (as that will be our main focus for implementing tests for, for the time being)? |
Reopening for discussion re: metrics of success - https://meta.wikimedia.org/wiki/Grants_talk:Project/Improve_%27Upload_to_Commons%27_Android_App/Renewal#Metrics_of_success_-_Google_Play_ratings_vs_survey |
This has been approved. |
Uh oh!
There was an error while loading. Please reload this page.
After this IEG round is over (basically, just the final publicity step and the final report left), I intend to apply for a renewal.
UPDATE: The final draft is available at https://meta.wikimedia.org/wiki/Grants:Project/Improve_%27Upload_to_Commons%27_Android_App/Renewal . I am no longer updating the opening post.
Tasks
Please bear in mind that the time estimates below are not just for development, but also for testing, getting user feedback and fixing any issues with implementations
'Nearby places that need pictures' enhancements: (1.5 mths)
Quality of life improvements: (1 mth)
* [Not included] Add support for videos? Add support for uploading and recording videos #4 (not sure how much work this would take)
UI improvements: (1 mth)
[Not included] Make app more interactive:
* [Not included] Badges - I think we want to stay away from pure quantity badges like "200 uploads" so we don't inspire bad uploads. Rather, we could offer badges for quality, like when the user maintains a 90% no deletion rate, or when their pictures are used in articles or selected as picture of the day etc. Also not sure on the feasibility of this as it would require backend storage online #85
* [Not included] Add campaign support (not sure if feasible in addition to everything else, might take a lot of work). A "lite" version of this could be just displaying news about ongoing campaigns/competitions #78
Improve user education to improve uploads:deletion ratio: (1 mths)
https://github.com/commons-app/apps-android-commons/issues?q=is%3Aopen+is%3Aissue+label%3A%22user+education%22
Various important technical stuff: (1.5 mths)
Metrics of success
The text was updated successfully, but these errors were encountered: