Closed samanthasunne closed 2 years ago
There's a script outside of the main website that's supposed to aggregate the individual calendars into the global calendar: https://github.com/hackshackers/hh-events-aggregator
It's really complicated and prone to breaking, I think it would be best to retire it
Copying from emails between Lukas and me:
We talked about deactivating and removing the calendar entirely. I would still like to have some alert system for new events, though, if possible, even if it's just for Meetup groups.
Another idea is, could it potentially pull from the section of the newsletter, which I upload every week as Markdown file? You can take a look at the code in the blog directory and the events are listed in a section called “the week ahead“ if there are any. There aren’t events every week. I could maybe enter it in a different way, potentially if that would make it doable. Why don’t you take a look at that.
Thanks! Using the Markdown file sounds like a much simpler approach.
This upcoming events idea from the news section sounds perfect. I think it's higher quality information (ie. something people are more likely to travel for) than the weekly meetups, plus it plays nicely with what the format of the events used to be when working:
I'll start working on this!
Great call!
On Sat, Mar 27, 2021 at 2:32 PM Lukas Udstuen @.***> wrote:
This upcoming events idea from the news section sounds perfect. I think it's higher quality information (ie. something people are more likely to travel for) than the weekly meetups, plus it plays nicely with what the format of the events used to be when working: [image: image] https://user-images.githubusercontent.com/6817579/112730665-9c094000-8f11-11eb-9d31-f3f84b658912.png
I'll start working on this!
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hackshackers/hackshackers-hugo/issues/99#issuecomment-808783576, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHTN2MBYXA4C52JCQRI5X3TFYQE7ANCNFSM4V2TJ7IA .
I was taking a look at how to code this, with an eye on code reusability. @samanthasunne : Would you be OK with moving the upcoming events list from the individual news (blog) posts into a file in the data folder? It would look something like this: https://github.com/ludstuen90/hackshackers-hugo/blob/99-globalcalendar/content/data/news.yml
Then, as new events come up, you would just make sure to edit that file, instead, and all of the blog posts would update with the correct dates.
Why the change? I was looking at how parse the data if we keep it in the news post itself. Since we would want the most up-to-date information on the front of the site, we would always need to access the newest news post. The URL of the most recent news post is always changing (i.e. depends on the name of the post itself), and there isn't a sure-fire way to find it other than coding a clumsy parser that first downloads the list of all news pages, and then looks for the first item in the list.
Worse, this parser approach creates a dependency that our site looks this way. (IE: If two years down the road, someone decides to change the layout of the site, or the name of the news section, all of the sudden the scraper breaks again).
Since we have control over the data, I think it makes more sense to look at a cleaner solution.
If we move the conferences information into the data folder, then the scraper can just download the list from the repo, and go to town. The data would be stored as a YML file, the same format as used on other parts of the site.
In the actual news post, we would have a custom short code that looks like this (see the upcoming events section at the bottom of the page, and notice the actual events are not listed): https://github.com/ludstuen90/hackshackers-hugo/blob/99-globalcalendar/content/news/2021/03/meet-news-product-alliance-next-week.md
You would just have to make sure to include the tag, and the newest events would render:
The downside is you'd have two files to edit, but we don't create any dependencies on the site layout.
One final thing comes to mind: any time we update the events in the data folder, all of the blog posts would update to show the most updated information, even posts from months ago. We could clarify what's happening by putting a footnote on the page saying the events are always updating, so that way if someone is reviewing an older page, they wouldn't be confused.
Those are actually events around the world - we want to have an Upcoming Events section with just Hacks/Hackers events. Those are listed in the blog post section "The week ahead" if there are any
Ah, ok, makes sense - do you have a list of these ahead of time? It looks like you only put the events for the current week in the blog post; we could potentially keep the same approach, where we store all the coming events for the next months in a YML file, and pull from there for the homepage
That's correct - I include the upcoming events when I write the newsletter in a Google Doc, which is usually Friday afternoons. I get them from manually checking Twitter, emails and Facebook, so the Google Doc is where they first appear. It's a new GDoc every weerk.
I convert the GDoc to Markdown using an Add-On, then create a new file in the /news/ directory and copy and paste the Markdown text into it. I suppose I could copy and paste the events into a separate YML file, but I'd like to keep the workload down as much as possible. Is there a way to streamline it?
For instance, the event in this week's blog post is this bit of code:
**The week ahead:**
* London is [talking](https://www.hackshackersldn.co.uk) about writing books and understanding audiences
@samanthasunne Awesome, this is helpful to know. I'm taking a look at some of the older posts, and it looks like there's around 1 event per week, sometimes zero. How much of a backlog do you have with the events? From your comment, it sounds like a backlog might not exist.
On the one hand, I think the homepage would look best with 4-5 events listed -- otherwise even if we fix the feature, I think we could run into the same scenario we have now, where the site looked bare.
If having a few events in the backlog for the homepage sounds reasonable, then we could store them in markdown format in the data folder. Since for the H/H events, I noticed the posts are limited only to events in the upcoming week, this approach would include keeping a separate markdown file updated with the "backlog," or list of upcoming events to appear on the homepage. This file could, however, be updated with the same PR as the weekly blog post. Would just be another item to take a look at each week.
I'm noticing due to COVID there are a ton of online hacks/hackers events -- which, while it lists, would be a rich source of events to preview. https://www.meetup.com/es/Hacks-Hackers-Zurich/
On the other hand, if maintaining a list of events for the homepage is outside of capacity, we could always just turn the homepage into an upcoming "news" section and preview the blog posts.
I see what you mean about the "upcoming events" section not being relevant, since they're not H/H events. Good call!
Another idea: Rather than an "upcoming events" section, we could do a "things we're talking about" section. Link to any published blog posts, or tweets from hacks hacker organizations. I think a bit of manual curating is still important, as I'd be advise against automatically ingesting tweets from the different H/H groups and putting them on the homepage.
In conclusion, the options I can think of now would be:
How much of a backlog do you have with the events? From your comment, it sounds like a backlog might not exist.
By backlog, do you mean H/H events that already happened? That isn't an issue since I just list upcoming events in the weekly newsletters.
This file could, however, be updated with the same PR as the weekly blog post. Would just be another item to take a look at each week.
This would be ideal for me. I really don't relish the idea of having another file to manually update and maintain every week. How would this PR work? We can also schedule a call if that is easier to discuss this.
I hear you, the most we can reduce the extra work required each week the better. I think that's a good idea, how about we set up a call to talk through options? I will send an email to coordinate times!
Ideas:
@samanthasunne I started digging in a bit more to see how we could use the Meetup.com API, and I see that it requires a subscription to MeetUp Pro https://help.meetup.com/hc/es/articles/360028549711-Precio-y-periodo-de-prueba-de-Meetup-Pro I suspect this might have been why the earlier developers decided to go with the scraping option.
Eventbrite: We can use the API to to download event information, I would just need to work with the London team to get their organization ID.
Facebook: The Facebook API looks to be open and it shouldn't be any problem using it.
Given that we can only get data from Eventbrite and Facebook, I think it might be worth evaluating if we still want to go the route of trying to display the events, or add some other type of content.
From what we learned with the last automatic scraper, I think we would discard the idea of trying to write a new scraper, since it's prone to breaking.
This leaves us then with the options of:
Note: Current homepage code only shows upcoming events, not past events. Will need to simplify code to show all events, including, past events, as per discussion.
@samanthasunne Currently (although hidden now), the homepage says "Upcoming Events." How about changing this to "Featured Events," so that we can show both upcoming and past events?
Let's say "Recent Events" even though some are recently passed and some are coming up
As this has been merged in, assigning to @samanthasunne to close if acceptable. I noticed the homepage has its most recent event of November; this is because Hacks/Hackers London hasn't updated their site recently. The app continues to check every 6 hours.
The global calendar on the homepage hasn't shown any events for a few months now, even events on Meetup pages the calendar should be pretty easily linked to