Page MenuHomePhabricator

Reading List
Closed, DeclinedPublic

Description

Sometimes readers (but not ususally editors) stumble upon an interesting article and would like to read it later, maybe because they don't have enough time at that moment. That would be great if they could add it to their Reading List so that they wouldn't forget it! I know there are lots of ways to bookmark webpages (both by browser and online service providers) but this idea is worth considering.

4nn1l2 (talk) 10:28, 10 November 2015 (UTC)

This card tracks a proposal from the 2015 Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey

This proposal received 24 support votes, and was ranked #37 out of 107 proposals. https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Reading#Reading_List

Details:

  • Primary mentor: @Jhernandez
  • Co-mentor: @4nn1l2
  • Available for code review: @Jdlrobson
  • Skills: PHP, Javascript,HTML/CSS, familiarity with MediaWiki in general
  • Estimated project time for a senior contributor:
  • Microtasks:

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptDec 7 2015, 11:23 PM

As @Jdlrobson mentioned, this is what https://www.mediawiki.org/wiki/Extension:Gather does. It is installed on en wiki, he wiki and wikivoyage (maybe somewhere else).

You can see it in mobile web beta in use. We weren't sure how to migrate it to desktop but there are a few bullet points I can think about:

  1. Add it as a beta feature (currently accessible if you know the urls, but there is no link in the sidebar or way to get to there).
  2. Revise the editing collection to ensure it works on desktop.
  3. See how to expose the feature for desktop usage (saving pages), currently in mobile the behaviour is overload the watchstar to offer saving to watchlist or any other of your lists.
  4. Check how coupled gather is to certain mobile frontend modules and if that would pose a problem in desktop.
IMPORTANT: If you are a community developer interested in working on this task: The Wikimedia Hackathon 2016 (Jerusalem, March 31 - April 3) focuses on #Community-Wishlist-Survey projects. There is some budget for sponsoring volunteer developers. THE DEADLINE TO REQUEST TRAVEL SPONSORSHIP IS TODAY, JANUARY 21. Exceptions can be made for developers focusing on Community Wishlist projects until the end of Sunday 24, but not beyond. If you or someone you know is interested, please REGISTER NOW.
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptJan 21 2016, 2:51 PM
JMinor added a subscriber: JMinor.Feb 5 2016, 1:04 AM
DannyH updated the task description. (Show Details)Feb 6 2016, 12:03 AM
DannyH set Security to None.
01tonythomas added a subscriber: 01tonythomas.
NOTE: This task is a proposed project for Google-Summer-of-Code (2016) and Outreachy-Round-12 : GSoC 2016 and Outreachy round 12 is around the corner, and this task is listed as a Possible-Tech-Projects for the same. Projects listed for the internship programs should have a well-defined scope within the timeline of the event, minimum of two mentors, and should take about 2 weeks for a senior developer to complete. Interested in mentoring? Please add your details to the task description. Prospective interns should go through Life of a successful project doc to find out how to come up with a strong proposal for the same.
Sumit added a subscriber: Sumit.Feb 23 2016, 5:26 PM

As mentioned above, the requirement above is very similar to what Gather already does. Do we need a new direction for this task? Because I think we can rework the description within the scope of Gather itself? Thoughts?

I'm contacting the reading product team to see if we can get ownership of gather and morph it to be just reading lists.

@Haritha28 is interested so I'm researching to see if we can use Gather or we should make a new thing.

The collection extension can be used for this purpose. It's already in wide usage across many wikis.

This is essentially blocked on T46187: There is no way to merge a saved book with a "book creator" draft: if that was solved, users could make a collection "interesting pages" and then use the interface to add new titles gradually.

Optionally, this might also benefit from some tweaks in the storage methods (e.g. if we expect the user to build the list across multiple devices and/or to take unregistered users into account): T46185: Store created books on a server, not in the browser.

I suggest to rephrase the summary as "Reading list permanently editable via Special:Book".

01tonythomas updated the task description. (Show Details)Mar 1 2016, 3:40 PM
Haritha28 updated the task description. (Show Details)Mar 2 2016, 11:53 AM

Alright, looks like we have 2 mentors listed over here, but still lacks a co-mentor!

@Jdlrobson , are you sure you dont want to co-mentor this one ? Having one more mentor would make this project Featured for GSoC/Outreahcy in this round!

@01tonythomas I've strongly advised that the 2nd mentor should be a community member. How much time do we have to find one? If we can't find one we should at least have a community advisor.

If we cannot find a mentor, I could probably provide limited assistance in a mentoring role.

Sumit added a comment.Mar 2 2016, 8:30 PM

@01tonythomas I've strongly advised that the 2nd mentor should be a community member. How much time do we have to find one? If we can't find one we should at least have a community advisor.
If we cannot find a mentor, I could probably provide limited assistance in a mentoring role.

@Jdlrobson , see GSoC Timeline. Considering student applications open on 14th March, we have time till then or somewhat till after that.

Bawolff added a subscriber: Bawolff.Mar 3 2016, 5:53 PM

It'd be nice if this was the design and usecases of this was thought out clearly before hand. Gather was not what I would call a great success, I worry somewhat that this gsoc will basically repeat the same mistakes if we're not careful.

It'd be nice if this was the design and usecases of this was thought out clearly before hand. Gather was not what I would call a great success, I worry somewhat that this gsoc will basically repeat the same mistakes if we're not careful.

To be fair, the team working on this thought very carefully about the use cases for watchlist and private, it was moderation and public that was ill-thought out. Given that a reading list would be private I don't share this worry, but I do think a mentor from inside the community who can shepherd the initiative would be crucial for its success.

It'd be nice if this was the design and usecases of this was thought out clearly before hand. Gather was not what I would call a great success, I worry somewhat that this gsoc will basically repeat the same mistakes if we're not careful.

To be fair, the team working on this thought very carefully about the use cases for watchlist and private, it was moderation and public that was ill-thought out. Given that a reading list would be private I don't share this worry, but I do think a mentor from inside the community who can shepherd the initiative would be crucial for its success.

Thanks, that makes sense (although as an aside, i dont think ive ever seen any retrospective about how the private parts of gather were recieved. Having whomever does this project look into that might be useful - in order that they can copy the best parts and learn from any (presumably currently unknown) mistakes in the implementation of the private parts. Altough for all i know a retrospective may exist and im simply unaware of it). I still do worry though. Mostly because i think we should be extra careful with use cases on gsoc/opw projects, as gsoc students are typically not very well positioned to deal with mismatching user expectations, being new to our community.

Qgil added subscribers: 4nn1l2, Qgil.Mar 7 2016, 9:10 AM

@01tonythomas I've strongly advised that the 2nd mentor should be a community member.

What about inviting @4nn1l2, the volunteer who proposed the idea in the Community Wishlist survey?

As we can see from the survey votes and the comments here, this project idea has some question marks. Instead of being deterred by them, I would use this internship project as an opportunity to go deep in the Understand and Concept stages, aiming to deliver a strong reasoning of the need for this feature (are bookmarks in your browser or the Collection exception enough, what are the lessons learned from Gather, mobile apps, etc...), an analysis of the possible implementations, and then a functional prototype in Wikimedia Labs. Taking the full Plan and Develop stages for a project to be deployed in Wikimedia production would be too much, both in terms of technical work and community discussions.

Sumit updated the task description. (Show Details)Mar 10 2016, 4:04 PM
Sumit added a subscriber: Samtar.Mar 14 2016, 5:24 AM

@01tonythomas I've strongly advised that the 2nd mentor should be a community member. How much time do we have to find one? If we can't find one we should at least have a community advisor.
If we cannot find a mentor, I could probably provide limited assistance in a mentoring role.

@Samtar, as mentioned above, this project is blocked on having a co-mentor from the community who can act as a point of contact and guide the design-development-feedback process, keeping the community involved in the process. Feel like taking up the role?

4nn1l2 added a comment.EditedMar 14 2016, 9:22 AM

I just sent a mail to @Haritha28 and asked her to explain what mentoring involves and what exactly I am supposed to do. If I find myself qualified enough to take part in this project, I will be more than happy to help you.

@4nn1l2, I'm happy to serve as a "meta mentor" for you, i.e. as a mentor for the mentor. Is that something that would help you? I'm interested in helping community members like yourself learn how to influence feature development effectively. As @Qgil alluded to in T120756#2093665, there can be a lot of work to do before the first line of code is written.

Jdlrobson triaged this task as Medium priority.Mar 14 2016, 5:08 PM

Thank you @RobLa-WMF, @4nn1l2 for chipping in. I will wait for @4nn1l2's reply to make this project featured for Google-Summer-of-Code (2016) and Outreachy-Round-12

@4nn1l2 , https://www.mediawiki.org/wiki/Outreach_programs/Life_of_a_successful_project#Coming_up_with_a_proposal says that:

Find two mentors, usually one more technical oriented, the other one more product/community oriented

Would be great to have you on board!

Nemo_bis removed a subscriber: Nemo_bis.Mar 14 2016, 5:28 PM

@01tonythomas, I'm in!

@4nn1l2, I'm happy to serve as a "meta mentor" for you, i.e. as a mentor for the mentor. Is that something that would help you? I'm interested in helping community members like yourself learn how to influence feature development effectively. As @Qgil alluded to in T120756#2093665, there can be a lot of work to do before the first line of code is written.

Thank you @RobLa-WMF, your help would be really appreciated.

4nn1l2 updated the task description. (Show Details)Mar 15 2016, 9:29 AM

This sounds interesting, having a MediaWiki way of keeping track of articles through Reading list is good. I think i like the whole idea since this will not only go a long way by enhancing the way wiki users keep track of their articles "to be read later" but also gives a convention in the way this is done. This is a good GSoC project because it will like to work on the project. @Jhernandez, @4nn1l2 and @Jdlrobson, looking forward to working with you in accomplishing the task during the summer.

Jdlrobson updated the task description. (Show Details)Mar 18 2016, 10:22 PM
Qgil added a comment.Mar 31 2016, 9:33 AM

The Wikimedia-Hackathon-2016 starts tomorrow and this task is featured at T119703. We want to use T130776: Wikimedia Hackathon 2016 Opening Session to promote these projects and help recruiting volunteers to work for them.

If this task is ripe for hackathon work, please follow these instructions. If it is not ready, remove it from T119703 in order to avoid volunteers' frustration. Thank you!

kaldari updated the task description. (Show Details)Mar 31 2016, 10:42 PM
01tonythomas updated the task description. (Show Details)Apr 1 2016, 12:49 PM

I'm removing Wikimania-Hackathon-2016 tag and info from the description, as the task is a Google-Summer-of-Code (2016) task with mentors and students working on it.

JMinor removed a subscriber: JMinor.Apr 27 2016, 4:24 PM
MBinder_WMF closed this task as Declined.Jun 1 2016, 9:58 PM
MBinder_WMF added a subscriber: MBinder_WMF.

This task was declined as part of a batch-decline related to sunsetting the Gather project. Please ping (politely) if this task should be reopened. For more information, you can also see here: https://www.mediawiki.org/wiki/Extension:Gather

Samtar removed a subscriber: Samtar.Jun 2 2016, 8:14 AM
Jdlrobson added a project: Epic.
Sumit closed this task as Declined.Sep 14 2016, 6:50 PM

This task was declined as part of a batch-decline related to sunsetting the Gather project. Please ping (politely) if this task should be reopened. For more information, you can also see here: https://www.mediawiki.org/wiki/Extension:Gather

I think the major problem with Gather was that the collections was public[1] - this implementation makes private user reading lists, which would be accessible across devices. I still think its a super cool feature, and if there are plans to drop Gather, how about a new extension then for this one ? It can even feature for Outreachy as well.

[1] https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_130#Disabling_Gather.3F

Private collections might also be problematic for an Outreachy project as we have no formal infrastructure for storing private data. I believe the apps and the services team are exploring this so it might be best to see what they come up with first. (@JKatzWMF probably knows more)

I believe the effort to store private data across devices (T128602) is currently, tentatively slotted for Q4 (Apr-June 2017). Using watchlist infrastructure might be another way to do this-- but would require multiple watchlist functionality as well as a way to dilineate between lists you want to watch and lists you want to bookmark.

As a side-note, it is bittersweet that the proposal to make Gather private was so actively dismissed as a solution to the RFC to disable Gather, since there is such a clear interest in this functionality.