Use a static site generator for the CoTech website and host on GitHub Pages

@harryrobbins do you have any information on the features you commissioned? We have the jobs board on discourse - is it designed to replace that? I'd be happy to see how hard it would be to model individuals in Jekyll.

I believe it will be easier for people in all co-ops to contribute design expertise to the proposed solution as the barrier to entry is a knowledge of static HTML and CSS (rather than php / wordpress / docker etc). I think the concern about hosting goes away with this proposal as we could use Github Pages. If not hosting static content should be simpler than wordpress.

James addressed an idea about making it (somewhat) easier for non-developers to contribute. And we'd be more than happy to contribute to the learning group on Git/Github suggested by @asimong - I think the CoTech website would be a great place for people to dip their toes in the water of collaborating using git.

How does Jekyll work for reciprocal links (e.g. I click on a service and see the co-ops that provide it, and I click on the co-ops and I see the services they provide?)

Is it fair to say that updating the content (e.g. adding a new co-op, adding a new service) will become harder while editing the theme (changing the CSS, etc.) will become easier?

How does Jekyll work for reciprocal links (e.g. I click on a service and see the co-ops that provide it, and I click on the co-ops and I see the services they provide?)

We have this working already. You only need to list the services against a coop and that will mean those services will be listed on the coop page AND all coops offering that service will be listed on the service page, i.e. you only need to edit the data in one place. The latter is achieved using this code.

Is it fair to say that updating the content (e.g. adding a new co-op, adding a new service) will become harder while editing the theme (changing the CSS, etc.) will become easier?

That's true to a first approximation, but I think that content editing is only very slightly harder, while development, deployment and hosting are substantially easier.

It's also much easier to collaborate on content changes with the Jekyll/GitHub approach - as I've mentioned previously I found the Wiki + Wordpress workflow very confusing and error-prone.

I think people are attached to the things they are familiar with :)

I am not sure which way my bias goes, I default to making Jekyll sites if I can, but I also have been contributing to the docker-compose setup for cotech wordpress site [1]. I am probably slightly biased towards the wordpress site because it is the currently running one, and having worked on the docker setup for it.

In terms of more objective measures, I checked the equivalent template in the Jekyll [2] and Wordpress [3] sites. To my eyes those are pretty much identical. In both cases you are mostly editing plain HTML, with a sprinkling of code (liquid, or php) to fetch the data.

For project setup complexity, whilst Jekyll sites just require ruby (and bundler), people that are not already in the ruby world often have issues, especially with gems that need to be compiled natively (in this case the natively compiled gems are ffi and nokogiri [4]). If it was switched over I would advocate still having a docker version available for more predictable development environment. So far we have been able to get non-dev users to get the cotech wordpress site up and running locally with one command (docker-compose up) - and should be working across linux/mac/windows.

For ease of use for editing content I would tend to defer to whoever might be actually doing the content editing. I think this is not me. I occasionally meet non-dev people that are happy to use github ui for markdown content editing, but not many, although given this is co tech perhaps that ratio is higher. Personally, I prefer the github model for all the reasons stated by @jamesmead / @chrisroos, but again i don't think I will be doing much content editing.

The final aspect I don't know much about - the future plans for the website, if it is intended to have more dynamic features (signup, forms, email sending, search, etc) then Jekyll is obviously not a good fit for that need (unless embedded js solutions are good enough). Or perhaps the vision is for a static brochure site, and have a separate site with dynamic features?

/endessay

[1] https://github.com/cotech/website/pull/41

[2] https://github.com/cotech/statically-generated-website/blob/7cd609d6743509cd1925a264de44ccf7d9bbc657/_layouts/service.html#L38-L46

[3] https://github.com/cotech/website/blob/9dc2d44820d04039c8991b34688ad770d5d4dce4/web/app/themes/coop-tech-oowp-theme/views/service.php#L37-L41

[4] https://github.com/cotech/statically-generated-website/blob/2416ec49404e44463b859d8da614600b20c12d41/Gemfile.lock

Static HTML is ideal from a hosting point of view, however, although people have struggled with development of the WordPress site, nobody has had a problem with adding Co-ops, Services or Technologies -- I fear that this is what we would loose with a switch to a static site generator -- the ability for just about anyone from any tech co-op with a login to, very easily, add content to the site.

I agree with this. When new co-ops sign up, we ask them to add their details to the site. Considering that not everyone in the network has the same tech skills, my concern is that the proposed version of the site will make it inaccessible, and it will either fall back to the same people each time, or not get done.

I agree. Plus, if at some time we wanted the site to handle transactions between members (not necessarily financial) that would mean moving away from static.

What about the idea I suggested yesterday, that we select the technology that works best overall, with the best resonance with our co-operative values, and with the most overlap with other work we may want to do, and help each other learn it? Is Wordpress a good solution to handling transactions? I wouldn't have imagined so...

No, but why change twice?