Which stack should we use?

[rubenvarela]

Looks like we are leaning towards something static, but not a specific stack yet.

What should the stack look like?

[jicruz96]

I don't have the answer-- alas, I'm still a newcomer to this universe.

I'd say a good rubric is whatever stack has the lowest barrier to entry / lowest learning curve. As lean, modular, portable, well-documented as possible. Talking out of my a** beyond that. Can more experienced folks maybe make a small list of candidates?

[rubenvarela]

A good thing from Hugo for example is that it's easy to regenerate. It's written in Go and binaries are compiled for every platform, https://github.com/gohugoio/hugo/releases

[rubenvarela]

We can also use docker/lando to make the on boarding quicker for anyone that wants to work on the site.

I can help with this automation.

[jamesxv7]

I think that setting up a Docker env could be more challenging that configuring a Go/Hugo or Node/Gatsby environment for people with little dev experience. I believe in the power of Docker for automate infra but for this project I see that it will be more difficult to maintain and to document.

[rubenvarela]

I think that whatever we end up with, just having options, documentation and scripts would help ease the onboarding. It also helps with continuity in case something happens and increases the bus factor (not lottery, because if I won, I'd be in here even more!)

[ebetron]

Based on initial conversation, JAMStack might be an option.
It's great for static site generation.
A concern is how easy/difficult is it to create content (such as a press release or a blog post) on a JAMStack app.
A lot of them use a headless CMS, GraphQL or a Markdown Filesystem to store the content, etc.

[kpl007]

What's the most technically complicated feature of the website? If we can just use a really user friendly CMS then that might be the best approach as it makes it easier for contributors to manage the site.

[rubenvarela]

On the front end, forms. There are 3 that could get tricky.

• Most unique one would be a form that would create a issue/ticket on GitHub
• Contact Us
• Mailing List/Updates

[kpl007]

Gotcha. Is there a requirement to be able to have non technical users manage content?

[rubenvarela]

Not exactly.

The content would need to be vetted and approved before going live. That could include revisions and definitely an approval process. The workflow that @froi was talking about was going to be using GitHub so that all decisions and history is public. It would also give us standard artifact if we ever have to move it out.

While the users might not have a technical background, we do have a vetting process that should cover formatting. We definitely could add a basic guide or even just link to the GitHub markdown documentation (if using GitHub flavored markdown). Also, on GitHub you can fork and edit a file and it will provide you with a WYSIWYG editor.

[rubenvarela]

@froi please correct me if I'm wrong on the idea.

[froi]

@rubenvarela that's correct.

The goal is to follow a PR workflow for anything that needs to go on the site. This includes our content.

The ideal situation for me is that we can have defined CODEOWNERS that would be the final say in PR approvals. This will let us define different code owners for content (think the _post folder in a Jekyll site) or for the code / functionality of the site.

[jamesxv7]

For the design elements and system we can use tailwindcss. Below is a sample / prototype of what could be done. This is just for reference, nothing official. The sections name were taken from the different discussions that took place at Hack Night.

[rubenvarela]

Hugo - https://gohugo.io

[rubenvarela]

Jekyll - https://jekyllrb.com

[jamesxv7]

Gatsby - https://www.gatsbyjs.com/

[froi]

I'm partial to use Gatsby. Most of the functionality that we need is pretty much out of the box. The functionality that isn't can be handled with plugin/extensions.

It will probably let us make the site simpler to share and reuse for more complex projects that might come in the future.

If everybody is ok with this one I'm going to call it.

[dom-wr]

I'm good with it

[rubenvarela]

Sounds good to me too

[jamesxv7]

I think next step should be to write the ReadMe file with all the steps to setup the dev environment. I can help with this if there is a baseline based on previous project. If its to do it from scratch, it will take me more time.