Consider whether RubyConf AU should be conference.ruby.org.au

[quintrino]

Should we switch to a url within ruby.org.au or keep it seperate?

Ideally we should at minimum have ticket sales are for authorised users only, or the sign up process for RubyConf AU automatically signs you up for ruby.org.au

[Cueball]

Overall, I like the idea from the issue title 👍

Would suggest conf over conference

Long-standing convention to use abbreviated form, plus it's shorter to type 😁

"Ideally we should at minimum have ticket sales are for authorised users only"

AFAICT I understand motivation, but unsure about this; my concerns are as documented in #371

Thoughts on Conf Site

• Need to consider how to structure the site
  • Suspect most likely option for top level and year subsite is conf.ruby.org.au/<year>/
  • conf.ruby.org.au - app redirects automatically to "current" conf year
  • conf.ruby.org.au/YYYY - server-level HTTP redirect to "old" sites (for valid YYYY)
  • conf.ruby.org.au/conf-index - single page with list/links to all confs
  • Avoids each year's conf site having to incorporate a list of all past confs
  • Forget about year-based subdomain - tried it, worked, but seemed to cause confusion
• IMHO still think some form of SSG is ideal (see notes on 2024 conf ⬇️)
• Our successors will hopefully thank us for making it a static site
• Obvious that getting .ruby.au domain isn't alternative
  • Assessment: not likely to be resolved anytime in near future
  • If/when that does eventuate, mass migration of all services to that domain could be considered
  • auDA is expecting to review the .au domain rules in 2025H2 which may change this assessment

Context around 2024 change to conf site

• I'm the culprit to suggest moving from rubyconf.org.au to rubyconf.au (we did this for 2024 conference)
• Also recommended deprecating the "old" conf site
  • Contains all RubyConf AU sites prior to 2024
  • Old site used Sinatra
  • Was easier to put a "new" site onto a new domain and leave "old" content as is
  • IIRC very time-consuming to update site content
  • Also no official "maintainer"
  • Probably still in need of attention
• IIRC I suggested just using an SSG would be sufficient for "new" conf site
  • Suggested Bridgetown as a "decent" SSG that could deliver what we needed
  • Key factors were "easy to update" and "easy to maintain"
  • In hindsight, suspect Bridgetown wasn't the best choice
  • @leesheppard did the heavy lifting there on implementation - will defer to his opinion there
• Conf organisers have to be able to update site for max of 12 months
  • But c'tee needs to maintain site essentially indefinitely

So while the domain change wasn't really a problem, the choice of software for the conf site is much more significant