Details
-
Task
-
Status: Done (View Workflow)
-
Major
-
Resolution: Fixed
Description
In my original proposal for Jenkins 2.0, I called for the site to switch from Drupal to a static site generator.
This is something I personally believe in, and the feeling was shared by danielbeck and rtyler. In the past, Tyler has done a Jekyll based jenkins-ci.org prototype. Arquillian, my go-to example of what our website should be, uses Awestruct.
The goal here is to improve the community participation into the content by lowering that bar, and also secondarily reduce the infra overhead. We think the static site generator backed by a Git repo in the jenkinsci org achieves these goals.
gusreiber also walked me through the process of how one thinks about the website project, and he said that one of the important parts is to think about "information schema" to organize contents in, separated from what gets shown in what pages how. The system then should let us map those contents into actual pages, which is more in the hands of the designer (INFRA-372)
This ticket captures the preliminary experiment needed to validate these key assumptions. Either by putting together some kind of PoC, or just all-out copying how somebody else does this (such as Arquillian or the earlier prototype.)
swashbuck1r said he will check with gusreiber if this choice should be made by the designer of INFRA-372, if it should be done by us beforehand, or if it should be done collaboratively between us and the designer.
Attachments
Issue Links
- links to
Activity
The scope wouldn't be to replace the wiki AFAIK. But if somebody wants to write a post for the website, but somehow can't add a file on GitHub, I'm sure somebody could post it for them, which has happened for the current website in the past.
Though I agree that installing Jekyll (or Arquillian) would be a pain — I use Jekyll myself, and doing all that Ruby stuff is annoying, more so since they broke the config format and various things between versions at some point (at least in my experience, on Linux).
I've seen a few sites built with Hugo — http://gohugo.io/ — which is written in Go, i.e. it's delivered as a single dependency-less binary (or as a .deb, or homebrew package etc.).
I've created something using awestruct in this repository.
This is working out very well, so I'm going to stick with it
Depending on what the scope of the website is (e.g. is it just replacing what is in Drupal, or replacing Drupal + all of Confluence, or Drupal + some of Confluence) I think, if the goal is to lower the bar, things like the Arquillian example in my opinion wouldn't meet that goal and, in fact, possibly raise the bar.
As far as I can tell, and please tell me if I'm wrong, to do a change to a page you would need fork the Git repo, find the file that matches the content you are wanting to change, change the file, then create a PR for the change. If you wanted to actually make sure it looked like the correct sort of change you'd need to install Ruby and associated GEMs to be able to check your change? This would also imply that people would have to have a GitHub account presumably.
Right now in the Confluence style approach, you would just hit Edit, use the WYSIWYG editor to make the change, and then hit Save. Access is via a multi-purpose LDAP account.
To me the latter seems a lower bar than the former?