In order to remove live bookmarks we'll need a migration page that documents alternative applications, sites and/or add-ons that users could use to continue consuming feeds.

Doc for SUMO article: https://docs.google.com/document/d/1A51pHdem6iBRZDEy9pB8gBn2JtLOU1qTi4f2CMQQ7F4/edit?usp=sharing

We will also need to mention it in release notes for 63, I suggest that we use this bug for the release notes request as we will want to link to the SUMO article.

(In reply to Pascal Chevrel:pascalc from comment #2) > We will also need to mention it in release notes for 63, I suggest that we > use this bug for the release notes request as we will want to link to the > SUMO article. Talking to Marco, given 63 branches in just over a month and both of us have significant chunks of PTO coming up before then, we probably won't proceed with the removal within the 63 cycle. I would relnote for 64, so I don't think this should track 63. The only thing we've removed for 63 is opening feeds with web apps / registerContentHandler, in bug 1477670. Note that registerContentHandler is already scheduled for removal in 62 anyway, so the only reason people would see breakage in 63 is if they either installed a feed reader via a website's JS prior to 62, or if they manually (via about:config) added extra web-based feed readers. I would suggest dealing with any relnotes you want for that in bug 1477670. Personally, I'm not convinced we need to relnote that change, but ymmv.

(In reply to :Gijs (he/him) from comment #3) > (In reply to Pascal Chevrel:pascalc from comment #2) > > We will also need to mention it in release notes for 63, I suggest that we > > use this bug for the release notes request as we will want to link to the > > SUMO article. > > Talking to Marco, given 63 branches in just over a month and both of us have > significant chunks of PTO coming up before then, we probably won't proceed > with the removal within the 63 cycle. I would relnote for 64, so I don't > think this should track 63. > > The only thing we've removed for 63 is opening feeds with web apps / > registerContentHandler, in bug 1477670. Note that registerContentHandler is > already scheduled for removal in 62 anyway, so the only reason people would > see breakage in 63 is if they either installed a feed reader via a website's > JS prior to 62, or if they manually (via about:config) added extra web-based > feed readers. I would suggest dealing with any relnotes you want for that in > bug 1477670. Personally, I'm not convinced we need to relnote that change, > but ymmv. ok, given this information, I am removing the tracking flag for 63 on this one. We usually relnote what changed in the product which means new features but also feature removals, but yes, ymmv :)

Given that Thunderbird can handle feeds, should/can this be mentioned as an alternative?

Draft of the SUMO article is ready for review. Gijs, it looks like you are both currently out on PTO, but when you get back, can you review the article or let me know if anyone else should review it prior to publication? Thanks!

joni once gijs has reviewed it please review it, i guess we want to release this in the 63 beta cycle or even a wee bit sooner

The article has been published and findable through direct link only. Please let me know if we need to make this visible in search: https://support.mozilla.org/en-US/kb/rss-feeder-replacements

(In reply to Joni Savage ("need info" me) from comment #8) > The article has been published and findable through direct link only. Please let me know if we need to make this visible in search: https://support.mozilla.org/en-US/kb/rss-feeder-replacements Thank you for setting up this page. Unfortunately there are some problems. Article: * Please fix those links to addons.mozilla.org and www.wikipedia.com by adding https://. * The section about Content Discovery (Pocket) could be negatively perceived (mockery) and should be entirely removed: Journalists and advanced end-users use RSS feeds to have a complete overview of decentral, consciously selected and trusted news sources. The term Content Discovery often stands for radicalization on YouTube, commercial recommendations and clickbaiting. Personal experience: Pocket suggestions on the new tab page are days old, in very most cases already known and therefore boring. And, most importantly, it does not reflect previously mentioned values. * Please add Thunderbird and Livemarks (bug 1477667 comment 47). Product failure: * With knowledge that especially RSS users - as the idealistic ones who install Firefox on others computers - turn off telemetry Mozilla wants to remove an ancient implementation for technical reasons without replacement (missing or bad product decision/coordination). * With offerings like Advance you show an unbreakable will to Big data and centralization. * It is absolutely sad that the address bar menu contains "Email link", Pocket and Screenshots, but not an RSS icon with a Photon-style sub menu of available feeds. The problem is that Pocket - as a centralized service - is extremly advertised and in contrast a core feature of a decentral, personal trust-based and conscious web shall be removed instead of being advertised as well.

I agree that it would be good if Thunderbird and Livemarks could be mentioned directly, but is there any problem with me changing the Wikipedia link so that it points directly to the article on RSS readers at this url: https://en.wikipedia.org/wiki/Comparison_of_feed_aggregators ?

Thanks, Jan and Seburo. Seburo, if you could go ahead and fix the broken links, that would be great. We explicitly made a decision not to add a preferred RSS client to this article, Thunderbird or not. I will, however, see if we can add Livemarks to the AMO collection for feed readers.

(In reply to Seburo from comment #10) > is there any problem with me changing the Wikipedia > link so that it points directly to the article on RSS readers at this url: > https://en.wikipedia.org/wiki/Comparison_of_feed_aggregators ? I made that revision to https://support.mozilla.org/en-US/kb/rss-feeder-replacements and some other small changes. About the article title, "RSS Feeder Replacements". Should "RSS Feeder" be changed to "RSS Feed reader" or just "Feed reader"?

(In reply to Alice Wyman from comment #13) > About the article title, "RSS Feeder Replacements". Should "RSS Feeder" be > changed to "RSS Feed reader" or just "Feed reader"? just my opinion, but Atom feeds are also affected so the title should be "Feed Reader" and not "RSS Feed Reader" (the URL should also be changed).

(In reply to Sören Hentzschel from comment #14) > (In reply to Alice Wyman from comment #13) > > About the article title, "RSS Feeder Replacements". Should "RSS Feeder" be > > changed to "RSS Feed reader" or just "Feed reader"? > > just my opinion, but Atom feeds are also affected so the title should be > "Feed Reader" and not "RSS Feed Reader" (the URL should also be changed). I agree. I'll NeedInfo Joni Savage about changing the article title and URL. Just my opinion but I would also add "for Firefox" to the title, to make the new title "Feed reader replacements for Firefox". I also have a problem with the https://support.mozilla.org/en-US/kb/rss-feeder-replacements section, "What will happen to my existing live bookmarks?". The article should clarify what actions Firefox will take automatically (export live bookmarks to an OPML file, change Live bookmarks to static bookmarks when possible - see bug 1477667 under User Story) as opposed to what actions are suggested for users who wish to continue using those feeds (import the OPML file that Firefox created into a new feed reader). See also the ghacks article, https://www.ghacks.net/2018/07/25/mozilla-plans-to-remove-rss-feed-reader-and-live-bookmarks-support-from-firefox/ under the "What happens to existing Live Bookmarks" section for a description of what happens automatically.

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #9) > (In reply to Joni Savage ("need info" me) from comment #8) > > The article has been published and findable through direct link only. Please let me know if we need to make this visible in search: https://support.mozilla.org/en-US/kb/rss-feeder-replacements > <snip> > * The section about Content Discovery (Pocket) could be negatively perceived > (mockery) and should be entirely removed: Journalists and advanced end-users > use RSS feeds to have a complete overview of decentral, consciously selected > and trusted news sources. The term Content Discovery often stands for > radicalization on YouTube, commercial recommendations and clickbaiting. > Personal experience: Pocket suggestions on the new tab page are days old, in > very most cases already known and therefore boring. And, most importantly, > it does not reflect previously mentioned values. > <snip> The "Replacements for the built-in feed reader" section includes three paragraphs: Add-ons, Feed Aggregators, and this: (quote) Content discovery and presentation: Mozilla is working on various initiatives that provide similar functionality to RSS/Atom feed support, like Pocket [1](for aiding content discovery and selection by users) and Reader Mode [2] (for features like voice support and user-controlled styling of content). Rather than removing that paragraph I would move it to the Intro or to a different section. Pocket and Reader Mode are not replacements for the built-in feed reader and Live Bookmarks that are being removed. [1] https://getpocket.com/ [2] https://support.mozilla.org/en-US/kb/firefox-reader-view-clutter-free-web-pages

Good suggestions, Alice and Soren. I've changed the title and moved the paragraph about Pocket out of the "replacements" section and put it under an "alternatives" section instead. I've also reworked the Live Bookmarks section to add more clarity. Are we missing anything else? Feel free to edit.

(In reply to Caitlin Neiman [:caitmuenster] from comment #6) > Draft of the SUMO article is ready for review. Gijs, it looks like you are > both currently out on PTO, but when you get back, can you review the article > or let me know if anyone else should review it prior to publication? > > Thanks! This looks fine to me. Thank you for writing this, and thanks to others here who made helpful suggestions/edits. I think it's been reviewed enough that it's not necessary for anyone else to look at this point, though if you want more eyeballs on this you could ask :dolske, ::mak or :mhoye to have a look. Once we actually implement the removal and migration to OPML and so on, we probably want to expand on that (e.g. have details about how to get the OPML file / what the migration experience is like). Of course we'll try to make it as smooth as is reasonably possible, but explaining details in the SUMO doc will maybe help with people's concern prior to 64 being released - but it's too early for that right now. We can update it later if that sounds OK to you. The only other thing I'd say is that I'm not sure if the EOL date for ESR60 is set in stone at this point. Might be worth checking with relman if you haven't already.

Do you consider Brief (https://addons.mozilla.org/firefox/addon/brief/) as a good replacement? Is it possible to add it to the collection?

(In reply to Krzysztof from comment #19) > Do you consider Brief (https://addons.mozilla.org/firefox/addon/brief/) as a > good replacement? Is it possible to add it to the collection? I'm assuming this is one for Caitlin. :-)

Hey Kryzsztof, thanks for the suggestion! I'll pass Brief on to our editorial team for review.

(In reply to Tim Nguyen :ntim from comment #22) > https://addons.mozilla.org/en-US/firefox/addon/livemarks/ This is already in the collection.

Dark reader should really be removed from the collection, it has nothing to do with RSS feeds, it's just a dark mode for web pages.

See also bug 1477672 comment 5 about a proposed separate SUMO page, specifically about the migration.

This is effectively done given both https://support.mozilla.org/kb/feed-reader-replacements-firefox and https://support.mozilla.org/en-US/kb/live-bookmarks-migration . We can continue to update those documents but that can happen via the regular SUMO mechanisms, we don't need to keep this bug open for that purpose.