Skip to content
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

We should generate a feed.xml #1763

Open
bjohansebas opened this issue Feb 4, 2025 · 2 comments
Open

We should generate a feed.xml #1763

bjohansebas opened this issue Feb 4, 2025 · 2 comments

Comments

@bjohansebas
Copy link
Member

As the title says, we should generate a feed.xml file for the blog. We will probably need to split it into two files, one for vulnerabilities (@expressjs/security-wg) and another for the blog in general

@rowanmanning
Copy link

rowanmanning commented Apr 1, 2025

I'm interested in picking this up. I tried to subscribe via RSS today and would like to be able to! I have some questions:

  • Do you have a preference between RSS and ATOM as a feed format? Both are widely (universally?) supported by readers, I slightly prefer ATOM but happy to take direction

  • Should the feed include the full post content, just a snippet, or just a link to the post on the website?

  • Should the feed have a limited number of items? E.g. the most recent 10 posts? I'd be tempted to add this later if the number of posts becomes an issue (and it also maybe depends on whether we have full post content in the feed).

  • When you say a separate feed for vulnerabilities I assume you mean a feed only for posts with the vulnerabilities tag? If so, should vulnerability-related posts still appear in the main feed as well or should they be fully split? I'd be tempted to still include them in the main feed myself but your opinions might differ!

  • In terms of paths, feed.xml for the main feed and vulnerabilities.xml for the vulnerabilities feed OK? I'd link to both via link rel="alternate" on the home page.

  • Discoverability: where do we want to link to the feeds from, aside from link rel="alternate" in the <head>?


I'm also happy to just make a call on all of the above ☝ sometimes easier to make decisions like this in review.

@bjohansebas
Copy link
Member Author

Oh, this got lost in my notifications, sorry for the delay!

Do you have a preference between RSS and ATOM as a feed format? Both are widely (universally?) supported by readers, I slightly prefer ATOM but happy to take direction

i don’t have any preferences, not sure about the other members, but Atom is fine by me

Should the feed include the full post content, just a snippet, or just a link to the post on the website?

I’d say just the link, the important thing is to make the blog content get shared more quickly.

Should the feed have a limited number of items? E.g. the most recent 10 posts? I'd be tempted to add this later if the number of posts becomes an issue (and it also maybe depends on whether we have full post content in the feed).

I don’t think we have too many blogs, so I don’t see much sense in having a limit. The blog is currently for Express updates. There are ideas for more content on the blog, but they haven’t materialized yet.

When you say a separate feed for vulnerabilities I assume you mean a feed only for posts with the vulnerabilities tag? If so, should vulnerability-related posts still appear in the main feed as well or should they be fully split? I'd be tempted to still include them in the main feed myself but your opinions might differ!

A different feed for vulnerabilities, but those posts should still be in the main feed

In terms of paths, feed.xml for the main feed and vulnerabilities.xml for the vulnerabilities feed OK? I'd link to both via link rel="alternate" on the home page.

Sounds good to me, we can discuss it better in the PR.

Discoverability: where do we want to link to the feeds from, aside from link rel="alternate" in the ?

Other blogs have buttons to share content on social media, we probably need one too, but that would be another issue.

Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants