Proposal to Restart Static Site Migration Using Eleventy and CloudCannon

[dalesmith]

Dear community members,

A project to migrate the StackStorm WordPress website to a static site hosted on GitHub Pages was initiated last year but remains to be completed. Today, the website exists as a static site. However, the HTML files contain leftover artifacts from WordPress that make new content additions or changes to existing content extremely tedious and time-consuming. The original project intent was to replicate the StackStorm WordPress website's visual design by developing a custom Hugo template/theme along with Netlify integration (headless CMS) for content preview prior to GitHub Pages deployment.

A year has passed in which no community member has volunteered to create a custom Hugo template/theme nor has any member volunteered to work out the Netlify integration. In order to achieve our ultimate goal of a community website open to content contributions from across the StackStorm community, I would like to propose an alternative approach.

Here is what I am proposing:

1. Restart the Project from Scratch: I have access to an exact copy of the original WordPress site and I am ready to restart the WordPress to static site migration project in a local environment whilst the current public website remains - "as is".

2. Adopt Eleventy (11ty) for Static Site Generation: Given its flexibility and simplicity, Eleventy would more easily facilitate custom template/theme creation with its nearly unlimited support for templating languages that can be used together and independently in a single project. This templating support includes Nunjucks as a port of Jinja2 (a favored templating language among community members).

3. Utilize CloudCannon's CMS: CloudCannon's user-friendly CMS interface would make it easier for non-technical contributors to contribute content to the website. This aligns with our goal of welcoming content contributions from across the StackStorm community, i.e. sharing use cases, case studies and varied forms of content that tell the story of StackStorm's impact. CloudCannon's native GitHub integration facilitates a streamlined collaborative workflow while reducing or eliminating barriers to broader community engagement. And, we can leverage existing work on CI/CD GitHub Actions pipelines that deploy automatically to GitHub Pages.

4. Address All Currently Open Issues: Acceptance of this proposal allows us to consolidate and ultimately close the (7) existing open Issues related to the unfinished WordPress site migration, clearing the way for a fresh start.

I understand the community's affinity for Go and Hugo (as opposed to JavaScript-based Eleventy) and I respect that. However, given our current challenges and stalled progress on the Hugo front, I believe Eleventy and CloudCannon offer a practical and efficient path forward with benefits that extend well beyond underlying technology preferences.

I kindly invite the community to consider these points and share your thoughts, concerns, or questions. Together, I'm confident we can revive the website in a way that aligns with the original vision of creating a welcoming space for broader community engagement.

Thank you (in advance) for your consideration.

[cognifloyd]

1 - Restart the migration: ✅ Awesome. Sounds good to me 👍. Thank you! 2 - Using Eleventy vs Hugo: This is where I think we need to focus discussion. 3 - CloudCannon. Let's punt on this until later - If something like CloudCannon requires a particular kind of template, that would be good to know. But other than that, I think we can table that until we've finished migrating to a Static Site Generator. 4 - 🎉 Hooray for closing issues and making progress on stackstorm.com migration to github pages.

[arm4b]

To recap a few notes from the previous TSC meeting and adding more details about pros/cons:

2. Adopt Eleventy (11ty) for Static Site Generation

Based on the discussions, Eleventy is a Javascript-based tool (npm).

Historically, the Javascript-based tools didn't work well with the StackStorm Python opensource community. It could be because the average st2 user is DevOps/SRE/Security/backend folk and so the skillset is different in this group. At this moment I don't know any TSC members who's happy or interested to work with the Javascript tools. Three examples:

• st2chatops - abandoned, despite being critical core component of the StackStorm.
• st2web - stackstorm core component, not maintained, just a few contributions by the partners. Lots of security issues and update problems.
• api.stackstorm.com generator - something broke in the upstream dependencies resulting in a broken build. It was fixed once, but nobody was ever curiouris to look at it and fix for 2 yrs. ^^ all this Javascript-based repos have huge amount of technical debt already like updates, security, bugs, etc.

From the other side, with the most recent talks, what I liked about Eleventy is that it can work with the Jinja templating. I also took a look closer and, sadly, despite our conversations, it doesn't work like a React-like in-browser rendering, so just a static site generator as any other tool.

My impression is that Eleventy is a technically superior, but technically ideal is not always the best choice, considering the team/expertize context. What would work for sure is the toolset that's more likely to be used long-term by the TSC, Maintainers and Contributors. Every tool/process that's introduced is something that's needed to be then maintained by the TSC and so people optimize for the lower maintenance burden where possible.

Usage statistics by the platform shows Eleventy as unpopular one compared to Hugo:

In the past when someone proposed Hugo, - it got immediate agreement as a first go-to system candidate, because its popularity, Go/toolset and wide familiarity working with it.

^^ Something to keep in mind when making the informed pros/cons decision.

3. Utilize CloudCannon's CMS:

a) Yeah, the advantage with the CMS is the ability to do nice management of the website content. A few concerns about CloudCannon:

• Security. We're trying to make sure any 3rd party tool can't write to the repo. Is it a Github pull-based service only or needs write Github integration/access?
• CloudCannon is paid. We're trying to avoid any 3rd party or paid services for maintenance/bus factor reasons as well. See https://github.com/StackStorm/community/issues/36. Any paid system increases dependency rate and amount of moving pieces, harder to manage.
• With paid system onboarding/offboarding users is a difficulty. It should be an outside contributor and community friendly, which is not the case for CloudCannon.
• Ideal fit for OSS community like StackStorm is allowing people to run the CMS as an (optional) helper locally on their machine and propose a PR with the changes based on that. Examples: https://github.com/julianoappelklein/hokus, https://quiqr.org/, https://github.com/tinacms/tinacms

Overall it feels more like an optional thing, wondering to know how the workflow may look like with this new CMS.

b) Netlify, mentioned in the Enable Netlify integration (preview) #3 is free for a starter plan and if we'd integrate it, - we need it just for the PR preview as a quick visual check (pull-based, no write permissions needed). See: https://www.netlify.com/pricing/#pricing-table-full-feature-list

Overall I agree with @cognifloyd that website generation tool goes first.

---

My take on this discussion is always making sure we're acting in the best interest of the StackStorm community/project long-term. Based on history dealing with various tools around StackStorm, there are more widely adopted tools. What was proposed by the previous maintainers in the past and after taking a closer technical look today, - I agree those would fit the project better 💯

[dalesmith]

@armab With all due respect, the logic of your argument would suggest that a particular technology, in this case JavaScript, should be held responsible for StackStorm project neglect.

Is it really necessary to remind everyone that Hugo is NOT a JavaScript-based technology. Yet, despite this fact, the StackStorm website SSG project has been no less neglected for well over a year now. How is it possible for this neglect to occur in the absence of JavaScript as the culprit?

I would suggest that blaming project neglect on specific technologies that some individuals personally dislike is unlikely to positively contribute to the openness, growth and vitality required for a Community to thrive and remain relevant into the future.

Furthermore, the puzzling and potentially misleading equivocation between technologies involved with StackStorm core and technologies involved with the StackStorm website are beyond comprehension. These are (2) completely independent, separate and distinct technology domains. It is no secret that the (3) technologies fundamental to pretty much every website in existence are - HTML, CSS and yes - JavaScript!

If one were to take seriously the argument put forth above, then the StackStorm website should be reconstituted in Golang for no other reason than to appease the personal biases and technology comfort zones of some individuals involved with StackStorm core.

In all honesty, I can easily visualize that project neglect within an open source Community has high correlation with the "openness" of that Community to contributors willing to invest their time, skills, energy, blood, sweat and tears to further the aims and goals of that Community. When contributor willingness to contribute is met with obstacles and obfuscations, then they will obviously (and rightly) move on to other projects offering less friction and resistance. It is as simple as that.

Today, a casual observer of the StackStorm Community could rightly question whether this Community honestly intends to remain relevant well into the future. The current trajectory of creeping obscurity will eventually be succeeded by an obvious and irreversible atrophy, at which point it will be too late to identify a culprit technology to hold accountable for pervasive project neglect.

Lastly, I am no less motivated, no less interested and no less enthusiastic to proceed with the StackStorm SSG project as proposed above.

However, I certainly respect that this Community's leadership has every right to consciously prefer that the SSG website project remain neglected rather than accommodate contributors whose skill sets and technology choices (specific to this website project) may differ from the leadership's technology preferences (specific to StackStorm core).

[arm4b]

the logic of your argument would suggest that a particular technology, in this case JavaScript, should be held responsible for StackStorm project neglect.

No, there is no connection between the specific technology (Javascript, Golang, Python, etc) and why this specific Migrate StackStorm blog and CMS to GH Static Pages #76 project wasn't finalized 100% (5/7 tasks done). The project was left in between because people might switch focus to other priority tasks, have no time anymore, interest, didn't see enough value, or leave the project, whatever it is. You see the project as an overall failure, we see the fact we could already escape Wordpress as an improvement. By migrating out from Wordpress to GH static pages the most important achievement was done and we solved a lot of problems already like security, access control, transparency, ability for external collaborators to contribute and change the website via PR. The next task was to add a Hugo theme, which would make the process of adding new blog posts easier and friendlier. The task is Hugo template for stackstorm.com #4 where we would happily accept help.

Speaking of the choices. Every team is unique and has its unique technology radar where they prioritize specific languages and technologies they're already familiar, have experience with or want to work with in the future. Check out https://dzone.com/articles/what-is-tech-radar-why-teams-need-to-have-one, an interesting read. Javascript is lowest in our list and we're not just trying to avoid it, but also replace some of the Javascript projects with the other technology where possible. Your effort to bring another node framework doesn't fit that strategy plan and vision. We reviewed your proposal (thanks for the effort!) and several people gave feedback that initial Hugo still fits better compared to Eleventy. It's not that technology or language is bad, it's just something that will be easier and higher chances to develop as a larger group and reduce the bus factor and maintenance burden (check out https://www.getclockwise.com/blog/what-is-your-bus-factor). Every adopted tech is something that automatically becomes a responsibility and will be maintained by the members and contributors and where team members should be interested and be able to collaborate on. This is an important aspect.