Move bnb/join to nodejs/join or nodejs/meet

[bnb]

I've gotten a bit tired of having to open up the GItHub issue for meetings just to access the join link, and I'd rather not fill up my bookmarks bar with random join links.

Inspired by a single page that @davidguttman made for the Mentorship meeting, I've built out bnb/join. I suppose could it be considered a tiny static site generator, but its purpose is to automatically build an index and individual redirect pages for every project defined in a JSON config file that can easily be deployed to GitHub Pages so we can have permalinks for each meeting.

Here's what the config looks like (and here's a link to the whole config):

    {
      "name": "Technical Steering Committee (TSC)",
      "filename": "tsc",
      "link": "https://zoom.us/j/611357642"
    },

And it builds (where nodejs is the GItHub org and join is the repo name):

• A page called tsc.html, published to /docs. When used in conjunction with GitHub pages this would be published to https://nodejs.github.io/join/tsc. That link would redirect to whatever the value of link is in the object.
• A list entry in the /docs/index.html file so if someone goes to https://nodejs.github.io/join they can launch from there.

You can see this at work right now:

• Any of the following links work:
  • https://bnb.github.io/join
  • https://bnb.github.io/join/commcomm
  • https://bnb.github.io/join/tsc
  • https://bnb.github.io/join/modules
  • https://bnb.github.io/join/website-redesign

For initial landing, this could simply be a repo in the org and we could use the nodejs.github.io/<repo> links. If we wanted to add something like meet.nodejs.org, meeting.nodejs.org/join, or join.nodejs.org we could very easily do that with a CNAME file/setting in the repo.

What problems does this solve? These are the ones that I see it solving:

• One permanent link, forever. We won't have to switch Zoom links in calendar entries, in meeting automation tooling templates, nor anywhere else. If the Zoom link needs to be updated, it's a simple PR. If we move off of Zoom to whatever the next cool meeting platform is, we can update the link through tooling. This also enables project members to get this work done themselves without needing to ask a Calendar maintainer to do it for them.
• Memorable links. The various options we have to implement this are all actually memorable, allowing us to lower the barrier to hopping on a call. It's a tiny improvement, but it's one I get caught on a lot. I'm generally a fan of reducing the burden on us as maintainers wherever possible 😊

[mmarchini]

cc @nodejs/tsc @nodejs/community-committee

[bnb]

Updated slightly, accidentally did the wrong combo of shift and enter which created the issue a bit before it was fleshed out fully 👍🏻

[nschonni]

What about adding the links to https://nodejs.org/en/about/working-groups/

[mmarchini]

The page is really long, as someone who can easily have 4+ foundation meetings in a week, having a single place with easy access seems really beneficial.

[bnb]

@nschonni a large part of the point of this is that it's automatically generated and can be easily accessed from a memorable URL in a repo that's easy to maintain. Including that in the working groups page makes less easy to access, harder to automate, and doesn't give both a focused place and a single, low-maintenance and memorable url per group.

Also, that page seems to be entirely unmaintained as Evangelism was moved to the CommComm and dechartered a year or two ago 😅

[nschonni]

Yup, i'm definitely not the target audience for this 😄 . Maybe I'll just re-frame my comment and suggest a more general, integrate it with the existing .org or .dev repos as a /meet instead of a new site

Might also go well with https://github.com/nodejs/nodejs.dev/pull/890

[mmarchini]

I think having a nodejs.org/nodejs.dev DNS entry is a really good idea, but keeping it separate and using GH Pages is probably simpler and more approachable than sharing code with the website repositories (and is easier to automate with Actions if we want to). Note that we already have precedence for this, https://benchmarking.nodejs.org/ is not a part of https://github.com/nodejs/nodejs.org, instead it is dyanmically generated by https://github.com/nodejs/benchmarking/.

[mmarchini]

Also worth noting that there's nothing preventing us from moving it to the org and later moving it to the website repos if we find that useful/easier to maintain/easier for the target audience to contribute.

[bnb]

I'm not sure what the barrier to entry would be for something like join.nodejs.org or meet.nodejs.org but I've got zero issue with that. I'm happy with that or .github.io, but would definitely want to not stall on that ❤️

[mmarchini]

I'm not sure what the barrier to entry would be for something like join.nodejs.org or meet.nodejs.org but I've got zero issue with that

Creating a DNS entry is entirely separate from where the code will live, so it should have no influence on entry barrier

[MylesBorins]

+1 on creating a DNS entry and publishing via pages.

Here is an example github pages deploy action if that is helpful https://github.com/tc39/proposal-top-level-await/blob/master/.github/workflows/publish.yml

[bnb]

Sounds like we have rough +1s for DNS. In that case, I'd like to propose join.nodejs.org. The URLs would then be join.nodjes.org for the index and join.nodejs.org/<filename> for each entry, assuming GitHub Pages doesn't require file extensions when you're doing a CNAME for non-index pages (it doesn't do this for .github.io)

@MylesBorins I'll work on getting that set up in my repo before we transfer (should be able to get it done today) 👍🏻