Gather ?https://en.m.wikipedia.org/wiki/Special:Gather/all/recent

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.

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?

@Sumit: The Reading team is currently working on T127509: Uninstall the Gather extension from en.wikipedia.org

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".

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.

In T120756#2081246, @Jdlrobson wrote:

@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.

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.

In T120756#2085066, @Bawolff wrote:

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.

In T120756#2089133, @Jdlrobson wrote:

In T120756#2085066, @Bawolff wrote:

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.

In T120756#2081246, @Jdlrobson wrote:

@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.

In T120756#2081246, @Jdlrobson wrote:

@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?

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.

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!

@01tonythomas, I'm in!

In T120756#2118603, @RobLa-WMF wrote:

@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.

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.

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!

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.

In T120756#2346927, @MBinder_WMF wrote:

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

Thanks @01tonythomas . CC @JKatzWMF

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.