Closed dvzrv closed 8 years ago
I recommend using Jekyll instead of Pelican - it uses MarkDown all the same, but is supported by GitHub Pages directly, which means that any github repository containing documentation can be automatically rendered as GitHub Pages site, without any need for additional administration at all.
why not using the c-base wiki?
@berlincount good thinking. Have never used it though. @woodworker Because you can't interface it with a simple text editor. That is kind of painful.
If we want to use the wiki, which would be fine by me (I just don't like the way to edit wikis), there's just the annoyance of having to log in every time you want to read the documentation. Wiki needs cleanup anyways -> new issue
only internal is login to read, everything else can be read logged out and the wiki is there, it's just me being lazy and don't create even more places to collect information
Alrite, suppose using the wiki will be the easiest option for us.
The coundlab needs proper documentation and rulesets to avoid breakage of hardware, useless fights and provide a workflow that can be as convenient and flexible as possible.
I therefore propose documentation done with a small pelican (http://blog.getpelican.com/, http://pelican.readthedocs.org/) based website. Content can be written in ReStructuredText or MarkDown (which should be convenient enough, I hope), images, tables, etc. are easily used. The coundlab repository could therefore be turned into a pelican project, downloaded (regularly) to the working machines in the coundlab and be used on the localhost as a lightweight plain HTML based documentation. Running (i.e.) nginx to serve these few pages should be no problem at all and also pose no issue concerning ressource drain on the working machines.