Content and Goals

[blinklad]

It'd be nice to have a high-level overview of what the CTS websites' goals are (and aren't) even though this seems like a pretty simple design through a quick peek in the code -- although some of the data persistence details are fuzzy. Some thoughts, without knowing any of the concrete goals:

1. Dynamic vs Static content

It looks like data is mostly write-only for end users and any 'dynamic' content is pretty trivial. We could save a lot of time by using a tool like Hugo for static website generation, and using their data templates + serialization to whatever format we want (JSON, YAML) for any "dynamic" content.

2. Static benefits, Hugo

Further supporting a static website is the ease of maintenance, it's very easy to pass on these kind of tools to newer CTS members in the future. Additionally, Hugo in particular has very pretty templates and styles -- and if it matters at all, is licensed under Apache 2.0 so it's permissive if that matters to the CTS at all.

3. Short and Long-term goals

Issues are a great way to assign and track individual (and identifiable) units of work; this would also work nicely in tandem with the README.md providing higher-level information. They fit somewhere between inline TODOs and overviews. I think the scope of this site isn't such that it would matter a great deal but it helps organize our thoughts a lot.

4. Hosting

I assume that either @ryancarins or @danielcornwell88 will be using their Pi's to host this, correct? Or are we going to use Pages or something else? Depending on which route we go, some form of continuous integration (even just spellchecking on push) would be great so everything is set-and-forget.

[ryancarins]

Points 1-3

I've attached Dan's Requirements Document which I've been meaning to rewrite and add to the readme file but I haven't had the time yet. Hugo looks like an excellent tool and I'm open to the idea of using it, however I've been thinking of using this website as an example for helping web development students so Hugo might not be the best fit. It'd be good to get input from @danielcornwell88 as we should make the decision as a group and he is the person that requested the website to begin with.

Hosting

We haven't decided where the website will be hosted yet but for testing purposes it is being hosted on my pi and you can look at it here. Continuous integration is a good idea and we can certainly discuss options for it, personally I have no experience in the area so I welcome recommendations.

[blinklad]

That's a fair point RE: web development. I suppose the fact that it is a simple website makes it easier to use it as a tool for that. Hugo could be a good backup if the idea doesn't land well or it takes time to propagate and @danielcornwell88 decides a MVP is more important for the time being.

I went ahead and added the requirements to the README.

CI is definitely a rabbit hole but it's a very well supported workflow at any end of the project. There's abstractions available on Github, such as actions, but if we want to run simple but ad-hoc tooling (eg. run Aspell + Phplint + xmlvalidate) on new pull requests, that's when we'd have to move more things server-side.

Personally now that I think about the emphasis on using the CTS repositories as a vector for learning and deliverables through mentoring, very simple CI makes a lot of sense because it allows for contributors to adhere to internal consistencies and gain (automated) feedback instantaneously in an otherwise closed-loop (ie. the website is centralized & master branch closed) that may get a little busy during semester, executive changeovers and changing requirements. Furthermore it would help anyone working server-side to play around with CI tooling in a simple environment. So everyone is learning new skills and automating the boring stuff. Plus these kind of workflows are great ways to pad resumes by learning skills that uTas won't be teaching but are valuable for graduates.

[danielcornwell88]

I initially suggested using bootstrap and a W3Schools template to speed up development time, while not relying on something like wix or squarespace that controls the code base. The requirements are vague and need to be touched up, but the core website features are already quite generic and should follow good design principle as well for a website of this simplicity.

Point 1 that evan makes is true, I wrote the requirements to avoid making the deliverables too hard to develop. I could expect that a second iteration would create some kind of dynamic content. Which leads into point 2 which is that hugo, despite my very limited understanding, seems to be a strong choice for this particular stage, but may not support the dynamic content that a future iteration might create. In short, we want to maximize our ability to pivot, rather than create an fast and excellent, but difficult to rewrite product. I don't want to limit the creativity of future executives, this is a general theme of many of the projects that I've started, they allow future expansion.

We need to have an in person meeting at some point to decide on some concrete details and prevent any further confusion.