Move GitHub site source into sub-directory

[shonfeder]

If this repo is going to be home to the infrastructure configuration as per #93, then I think we'll want to reorganize it so that the source of the site is one sub-directory. The infrastructure configuration can then live in another directory, and other material we need to add over time (e.g., documentation or other source code) can also find a place.

This will require a bit of work to adapt the way we are deploying the GitHub page. No one on our team has permissions to configure that currently, and it would expedite this work if either @mtelvers or myself could be given those.

We are ready to start landing pieces of documentation and the ansible configuration here, so completion of this issues should be considered blocking work at this point.

This is something we've talked about in the team, but I'd like to be sure you're onboard, @avsm.

[avsm]

Why don't we just keep distinct concerns separate? The website can be in one branch, and the configurations in another branch. The problem with shoving unrelated things together is that you have to deal with lots of unnecessary merges. Is there ever a case where the website needs to utilise ansible scripts?

[shonfeder]

Our current thinking has been that the point of #93 was to colocate the infrastructure configuration (and other relevant code over time) and all of the documentation (including what is available in the site), as a move towards some level of monorepoization. So we've been expecting everything that "belongs together" (insofar as it servers to document or configure the OCaml infrastructure) to live side by side. In other words, my operating assumption has been that these are not distinct concerns.

If we instead want to keep the site separate from the infrastructure config then I'm not clear on the advantage of moving the ansible configuration into this repo. On the face of it, it seems to me that keeping two unrelated branches in the same repo is worse for discoverability then having two separate repos, since the latter is at least clearly visible from a GitHub search. I.e., if we don't want to collocate these resources, then I'm unclear on the benefits of #93.

The problem with shoving unrelated things together is that you have to deal with lots of unnecessary merges

I'm not sure what kind of unnecessary merges you're thinking of. Do you have a particular kind of scenario in mind?

Is there ever a case where the website needs to utilise ansible scripts?

We don't have concrete plans at the moment, but here are two possible scenarios that come to mind:

• Ensuring blog post updates accompany the deployment of infrastructure changes, by compiling release notes from a changelog kept for that purpose.
• Generating (parts of) the documentation of the machines from the ansible scripts (or using a common source of data for both).

As the documentation is extended to make the infrastructure more accessible to the wider community, I'd expect more opportunities like these to arise.

I don't have strong opinions on this one way or another, personally, and look forward to reading your further thoughts.

[shonfeder]

Just a general FYI that while we work out our preferred policy here, we will begin iterating on a way to combine and organize the consolidated configuration and documentation in our form in https://github.com/ocaml-infrastructure/infrastructure . This gives us a public place to prototype and start sharing the configs etc., and to stage some well thought out changes to bring back here.