Introduce an Atom feed

[lylo]

Despite declining popularity, Atom and RSS feeds are brilliant for 'following' sites. Ruby Conferences is an excellent site but the lack of a data feed means it's difficult to keep up with changes to the site. This PR introduces an Atom feed to make tracking new conferences easy. Notes:

• Uses the Jekyll feed plugin
• Adds a new updated field to the conferences.yml data file to track the date/time when the conference was added to the feed
• Atom elements contain the event name, URL, date range, and links – the same as the listing page
• Extracted the date logic into it's own partial so it can be shared by Atom and the index page

[jonallured]

Hi @lylo, sorry for the delay in responding, I've been procrastinating on answering because I've been trying to figure out how I feel about this direction! When I started RubyConferences.org there was a feed and I updated it by hand as things changed. It ended up being so much work that I stopped and didn't hear any complaints which made me think no one was reading it. So that sorta makes me feel like any work in this direction is likely to have a small payoff.

On the other hand, I love RSS and read many feeds myself so I do like the idea of having a feed. I feels like the Right Thing To Do™️.

On a third hand, I'm not super excited about having an updated timestamp to manage. The solution you have here is pretty slick, but I worry us lazy humans will mess it up, haha.

So I don't know, I mean I really appreciate the work you did here, but I'm not sold on the overall idea. What do you think?

[lylo]

I'm clearly biased but the only change in process from what's in place right now is that now, when you add a new conference to the YAML file, you have to add an extra line for each conference to specify the updated datetime. I personally don't see this as a particular overhead. Are there any other contributors who would have an opinion?

Please don't feel obliged to proceed just because of my opinion though, it honestly wouldn't bother me at all if the PR was closed – I had fun writing it and that's fine with me 😄

[Morozzzko]

Do you think there's a way to automate the updated datetime using Travis or GH Actions? I think there might be a script that checks two commits and automatically adds updated if there were any changes

[lylo]

Do you think there's a way to automate the updated datetime using Travis or GH Actions? I think there might be a script that checks two commits and automatically adds updated if there were any changes

This would be ideal, but I'm not sure offhand. You'd need to figure out that the YAML file had changed, then determine which were new entries and update the timestamp on that. Personally I'd just ask contributors to the YAML file to add in a timestamp 😅

[Morozzzko]

Well, I think we've already got Danger – we could WARN if a file was updated, but it didn't contain an updated key. Think it would be a bit better though – a clear communication for everyone

[adarsh]

I'm going to close this in favor of #492.

RSS/Atom feeds are better suited for a dated sequence of posts, whereas this site is a database of events, so it makes less sense.

I'm open to revisiting this in the future with a fresh discussion if there is an angle I'm missing.

[lylo]

I was looking at the website today and I thought I'd revisit this. Looking at my original PR I wonder whether the problem with the updated field in the YAML is the name. If it were called published_at then maybe it makes more sense. If each event had a publication date (which is a legit thing, no?) then RSS makes total sense.

Personally I don't want all the world's Ruby conferences in my Calendar. I just want to be notified (via RSS, ideally) when a new event is published.

[marcoroth]

I think updating and maintaing the updated field seems like a lot of work. If it was an actual database it would be much easier, but updating the YAML file manually seems excessive. Especially since you'd want it to also update when there's a new announcment, CFP open/close and a few other things.

Unless we can somehow automate it using GitHub Actions.

[lylo]

I think updating and maintaing the updated field seems like a lot of work. If it was an actual database it would be much easier, but updating the YAML file manually seems excessive. Especially since you'd want it to also update when there's a new announcment, CFP open/close and a few other things.

Unless we can somehow automate it using GitHub Actions.

I take your point, but the use case I'm trying to address is so people can be notified when an event is initially created, nothing else. Hence the new idea of renaming it published_at.

It's only adding a single date field when you first add a new event to the YAML. After you've done that, there is no more work.

[marcoroth]

Oh my bad, I misread that. Yeah, I guess something like an announced_at/announced_on or published_at/published_on could work

[marcoroth]

Thinking about this, it could also power this #607 in an automated way.

[lylo]

This branch was woefully out of date so I've created a new, simpler one which you can see on this PR:

#704

If you still don't think it's warranted, no worries. I just thought I'd try again with a bit more clarity.