Before rolling this feature out, lets work with CE to discus the sync feature of Reading Lists with the community. How will it roll out? How will we test it? Privacy concerns, etc…
Thanks @Fjalapeno, sorry to be so late to the game here.
What is the problem?
In 2016 Android replaced its simple Saved Pages feature with Reading Lists. Reading lists allow users to bookmark pages into folders for reading offline or just for basic bookmarking. This feature initially was intended to allow "syncing" of these lists for users with multiple devices, or even users who want access to these lists across their interactions with Wikipedia (ie across apps and web). Due to overlap with Gather and related community concerns, this part was put on hold. The Android team has identified this as a major area of complaint from users (they expect lists to sync) and the iOS team has held off implementing Reading Lists, as syncing was seen as a "must have" for this feature. This RfC paves the way for these user stories/needs to be unblocked, initially for Android, then iOS and with web to potentially follow.
Because this is the first time we are syncing non-editor or preference data to a user account we want make sure concerns about privacy and data secutrity are heard and addressed. Additionally some editors may suggest that we instead adapt the watchlist system for this purpose, and we would like to clearly articulate why we didn't choose that route.
See this page for background (with more to come):
See also this task which is the underlying user research:
And this page which puts this effort in the larger context of lists/collections/offline/compilations, etc (aka lists of articles):
How does success of this task look like? How do we know when we are done?
For this initial task, success is a release of the Android synced reading lists features, with all reasonable concerns about privacy and related values concerns addressed. The community should be able to find the info they need around this feature easily and in straightforward language.
Is there any goal, program, project, team related with this request? Please provide links and use the corresponding Phabricator tags when available.
This effort is being led by @Fjalapeno from the tech side, with me on PM duty. The Reading Infrastructure team will be first, managing this RfC and service implementation. Then Android app team will do their front end work. Then iOS team will do their front end work. See the tags on this task for appropriate phab tags.
What is your expected timeline from start to end? Is there a hard deadline?
This effort is already under way (as mentioned this is, in a way, resurrecting a need that arose last year). This RfC and the publication of the wiki pages linked above is a more official "kick-off". The service is projected to go into beta in the next month, with Android update likely to come in late July or early August. iOS roll out would happen in September, with web TBD after. There is no hard deadline.
I was waiting to hear the result of the technical Rfc. https://phabricator.wikimedia.org/T164990#3421668
At this point, I think the next step is putting together an invitation to discussion, ask for translations, and post to the pertinent communities. Meta and Wikipedia makes the most sense to me.
It will be important to address:
- What was "overlap with Gather and related community concerns"
- How have they been addressed?
I think the immediate reaction, without this, will be "This is just Gather Lite and we said we didn't wait Gather." I'm not assuming user research before this reaction.
Agreed that these are things we should address proactively. I think our take on the end of Gather was that there wasn't so much objection to the basic concept of letting people make lists of wiki pages, focused on reading, but rather some key issues which the foundation failed to prioritize before the project got put on ice by various org-changes/reorgs. So I think the response/defense should focus on the specific objections raised to Gather, but thats just my $0.02.
The most direct answer is that reading lists are not public wiki pages and are not part of "Wikipedia". Gather's core was the publishing and sharing of lists and it was hosted on the particular language wiki. This was new content which was not subject to admin curation and didn't align with content policies (like lists could have NPOV titles).
Reading lists are private, stored as part of a user's account, not as a public wiki page. There is no sharing or publishing ability for reading lists, and none is planned. The target audience is people that read a lot of wikipedia content and want to bookmark and organize that content in the app (and eventually web), not potential new curators or social media users (as the target of Gather).
For 2, the same answer holds, though I'd add that we removed the gather extension and this work doesn't build on or reactivate that.
Ok, a page with some words on it is better than a blank one. I created a draft message. Eventually this message will be what we bring to the communities for discussion. Please edit and provide feedback on the talk page.
I got some feedback on the draft and am ready to mark for translation to post to local Village Pumps. @Fjalapeno, when you have a moment can you give it a once over?
Does it make sense to post to the language Wikipedias where app usage is highest?
I'm not suggesting excluding languages, but it would be easier to target a smaller number of languages when asking for translations initially. Then follow up with a broader notice/discussion with the rest of the communities.
Hmm, now that I said that, I'm not sure language/app use has any correlation as app usage is so very reader-focused. Just because the app is poplar in X language doesn't' mean that contributors at X language Wikipedia will have input.
Maybe I'm wrong. Some thoughts on that are welcome.
you can still try.
English, German, Italian, French, Spanish, Japanese, Dutch, Portuguese, Turkish, and Chinese were the ones we targeted with the WD descriptions in app initiative. (I don't know about Russian, as they had already been involved, but you can ask the team).
@CKoerner_WMF sorry, this slipped through my mail box…
I added some feedback to your wiki page. Looks good overall to me. You may want @JMinor's feedback there as well.
I talked to Mr. @JMinor and have marked the page for translation. I have requested transitions from our lovely volunteers.
I'll post the hopefully translated message in a few days, probably Tues/Wed of the coming week to the Wikipedia Village Pumps. @JMinor if you have any suggested targets (like perhaps by languages where the app is most popular) I can prioritize those communities first (and ask for specific translations).
I've received five full translations(!) but would like to have more before I post. Considering the importance of this discussion having it in local languages will go a long way. I've asked for a few more translations and will post once I have another round of translation. If this causes issues with any timelines, please let me know. I can post in English, but I would really hate to do so if I can help it.
It has been nearly two weeks, a check of many of the wikis show little to no discussion of concerns. Where there was discussion it was generally neutral (clarification requested more than anything).
Wouldn't it be useful to document this request for feedback at https://www.mediawiki.org/wiki/Wikimedia_Apps/Synced_Reading_Lists? This way if someone in two years says that this feature etc etc the team could show that feedback was requested when the feature was being planned.
Being more systematic at these processes might bring a bit of extra work today in exchange of potentially less work explaining things in the future.
I think Quim is asking for links to the specific threads where any kind of reactions has been registered. (In case, Phab is also a good repository for those, as this is where we document our support, and hence list everything we did.)