Next steps for the codebar website

[richardwestenra]

We've been struggling for years with performance and reliability on the codebar website. The central London chapter isn't able to send out emails anymore because of the cost, and because it takes down the website server having to send out so many emails at once.

At different times, people have floated the idea of rebuilding the website a bit at a time, using the 'strangler pattern'. e.g. You could

• start by just replacing the evergreen landing pages with a static service
• create a new event page and event admin page that starts with workshops but gradually replaces all the different types of events
• just build a new email system

However, the codebar website is complex, and rebuilding even a small part of it could take a skilled developer weeks or months of full-time work. I'm interested in people's suggestions:

• What needs replacing most urgently?
• What should we replace it with? It's mostly written in Ruby - would it be more maintainable by more developers in the long term if it were migrated to JS?
• How do we go about getting this work done? Do we know any companies who would be willing to donate a large amount of developer time to help get this done?

[brunogirin]

Some quick ideas (please correct me if I have anything wrong). The web site comprises the following:

• Landing pages
• Blog
• Tutorials
• Members (students, coaches) and workshop management

The tutorials are already separate and use a static web service (Jekyll) so it feels like a sensible technology to use to migrate the static (landing pages) and low update content (blog).

The members and workshop part needs a dynamic system and the current one works, with the exception of emails. So the first thing to look at would be the email service: what is being used now and should it be migrated to something else? (I use Mailgun at work and I find it great to work with) Going forward, it may be worth migrating the dynamic part to something else. One technology I'm experimenting with at work is a headless CMS with a lightweight dynamic site on top: I'm happy to report back on how it works once I know a bit more.

Based on that, the priorities seem to be:

1. Fix the email problem
2. Separate out the static and low update content to a technology like Jekyll
3. Work out a path for the dynamic part of the site

An additional question I have: considering there are more and more chapters, should the web site support multiple languages at some point?

[alextercete]

An additional question I have: considering there are more and more chapters, should the web site support multiple languages at some point?

I'm encouraging a group of people to start codebar Rio de Janeiro and one of the hurdles is the fact the website is all in English, so I can certainly see the appeal for this.

[jmbriano]

An additional question I have: considering there are more and more chapters, should the web site support multiple languages at some point?

We have an ongoing initiative in Barcelona to have the landing page in EN, ES and CAT(alan). As it is now, codebar barcelona is not safe for people that does not speak English. Because we use English, majority of our students/coaches are expats. We want to have more locals, but until now online and during the workshops only EN was used.

Having multiple languages support will definitely help in this topic

[matyikriszta]

@brunogirin @alextercete @jmbriano the website already supports multiple languages, you can add translations via Crowdin. For example check out: https://codebar.io/?locale=de. Of course we could improve upon the current implementation with a language select dropdown in the footer or something similar. This does not apply to tutorials, that site currently does not support multiple languages but I'd love it if it did.