How to deploy articles?

[Evrey]

So, this is a GitHub organisation. We could use the built-in Wiki, then. Pros: It exists. Cons: It's not trivially portable if we ever migrated all content somewhere else, and of course it's all bound to the GitHub UI.

So likely we'll be using a static site generator. But which one? Here's an incomplete list of candidates:

• Jekyll, built into GitHub Pages. All other static site generators need a little extra effort to be used for GitHub Pages.
• Hugo, pretty quick and feature-rich, can even do nested templates.
• Zola, RIIR for us Rust nerds. \:3

Also another question to solve, quick and dirty first, pretty in the long run if we find this project to actually take off:

• Who'll make the initial theme? (Must work without JS.)
• Who'll dictate the directory structure of articles and asset files?
• Licensing of articles? I assume some variant of Creative Commons?
• Who'll dictate what will and what won't be a usable shortcode in templated pages? Or is it laisez faire?

… Or just flood https://risc-v.repnop.dev/ =)

[MaxBondABE]

So likely we'll be using a static site generator. But which one? Here's an incomplete list of candidates:

* [Jekyll](https://jekyllrb.com/), built into GitHub Pages. All other static site generators need a little extra effort to be used for GitHub Pages.

* [Hugo](https://gohugo.io/), pretty quick and feature-rich, can even do nested templates.

* [Zola](https://www.getzola.org/), RIIR for us Rust nerds. :3

Also another question to solve, quick and dirty first, pretty in the long run if we find this project to actually take off:

I'll read up on this, I'm not very familiar, but I think rustdoc is a great example of what we should have as a feature set. Interlinking, searching. Searching probably requires JS though.

* Who'll dictate the directory structure of articles and asset files?

Issue #2 is very close to a directory structure. Maybe with subdirectories for drafts vs. released.

* Licensing of articles? I assume some variant of Creative Commons?

My preference would be CC0. I do think it's important we allow people to incorporate these ideas into commercial products, for instance, if the goal is to help foster the creation of NGOSs.

* Who'll dictate what will and what won't be a usable shortcode in templated pages? Or is it laisez faire?

My instinct is to start laisez faire and to create restrictions as problems arise. For instance, I gave all members admin permission, which probably isn't sustainable forever, but gives us the freedom to make whatever changes we sit fit for now.

Or just flood https://risc-v.repnop.dev/ =)

I do like the way this looks.

[MaxBondABE]

Also, I'm happy to write the necessary GHA YAML

[Stupremee]

I really like the idea of using something like Hugo, since that would give us a really customizable website, but still makes it easy to write the posts in Markdown or AsciiDoc. It will probably require quite some time to set it up properly and decide on a good theme, but I think it's worth the time.

However, it might be better to keep a more wiki-like style, which hopefully is possible with Hugo, otherwise, it would probably be better to use some hosted wiki or another tool that hosts some wiki-like page on GitHub pages.

Edit: I've done some research and I found https://wiki.brisberg.dev/, which is deployed using Hugo and might be a good inspiration.

[Evrey]

@MaxBondABE

I'll read up on this, I'm not very familiar, but I think rustdoc is a great example of what we should have as a feature set. Interlinking, searching. Searching probably requires JS though.

All mentioned static site generators can annotate all articles with tags, keywords, categories, etc., which can all be used for searches.

Issue #2 is very close to a directory structure. Maybe with subdirectories for drafts vs. released.

Most static site generators handle drafts via boolean flags in the article headers. Depending on the configuration the static site generators will then skip these articles during rendering.

My preference would be CC0. I do think it's important we allow people to incorporate these ideas into commercial products […]

It's not about licensing the ideas written about. It's about the articles themselves. As in what about forking this repo and spinning up an unofficial instance of the website. Or full-quoting articles.

@Stupremee I mean, Jekyll is pretty powerful, too. It's just a little beefier to install locally than Hugo or Zola.

[Stupremee]

I have no experience with Jekyll so I didn't mention it. But it might work too yeah

[MaxBondABE]

Just as a status update, I'm reading up on SSGs and github.io, but there's stuff I've got to do this weekend, so I won't be able to dedicate much time to this until Monday.

I propose that everyone who has a preference aims to express it by Wednesday, and we close the issue then and adopt the consensus tool.

[AltriusRS]

Having only ever worked with GH pages and (indirectly) Jekyll, im naturally more biased towards the things that I know and am familiar with, however having read through the preferences of the others here I have come to the conclusion that I don't think there is a "superior" tool for us to take advantage of here. I think no matter what, we should make use of GHP/Jekyll for hosting of the site to begin with, but regarding tools we use to generate the site's content, I do not have a preference.

[Evrey]

I have no preference. But using Jekyll is the least amount of head aches for GitHub pages, given that the entire render and serve pipeline is built-in. I'd only vote for non-Jekyll if others came and ranted about some super important Hugo or Zola or whatever features they absolutely cannot live without.

[1011X]

Since we're just starting out, I think it wouldn't be a bad idea to use whichever option has the least friction. If we run into any major issues early on, we can always try something else without much hassle. Plus I don't think we need very advanced features, at least not right now. So in decreasing order of preference, I'd go with Jekyll, then Zola, then Hugo.

As for licensing, I always prefer CC0, but I'm open to other options.

[Evrey]

As for licensing, i have a few suggestions for stricter-than-CC0:

• NC — non-commercial, so whoever forks off our wiki must not paywall the fork.
• BY-SA — If we allow people to publish copies of our articles, at least they must do so under the same license and state all changes they made.
• BY-ND — If we don't want to allow people publishing forked-off copies. This way, all additions to the wiki must go to our original.

So, i'd suggest we go for CC-BY-NC-SA-4.0 or CC-BY-NC-ND-4.0. Don't really have much of a preference here.

[Stupremee]

Starting with Jekyll sounds good. Someone should start to set up the basic skeleton of the Repository and start creating a style/theme we want. @MaxBondABE I saw you created the repository already, will you set up the basic stuff that is required?

[MaxBondABE]

@MaxBondABE I saw you created the repository already, will you set up the basic stuff that is required?

Yes, happy to.