This looks super cool. I do have a couple of tips that could potentially improve simplicity/maintainability.
So it looks like you’ve got a ruby project generating the static site onto the gh-pages branch. This is a cool workflow I haven’t heard of middleman-deploy until now going to check this out in the future for sure. GitHub does also provide it’s own static site generator for gh-pages, Jekyll. It’s also ruby based so should come naturally to you. This one’s useful because GitHub auto builds jekyll pages so you could set it up and forget it. This can improve your student’s experience with their first PR by making the experience for merging the PR and seeing it go live be instant.
ie: As soon as their PR gets merged into master it shows on on the github-pages page.
This feedback is inspired by one of GitHubs own fully automated PR tutorials (this one is allot more advanced in its automation) https://github.com/githubschool/open-enrollment-classes-introduction-to-github
I’d advise giving that a go, its quite satisfying to have your PR instantly merged in and visible.
On the jekyll side, you can find an example of what it could potentially look like here:
This is our society page and the committee exists in a data file (this is jekyll specific). So essentially you could have a teams.yml file with your students in and they could simply append their data to it in a pr, or even have a directory with subfiles say
_data/students/anna.yml brian.yml etc And then on the frontend just go through that file and print it out.
Love the idea, good luck.
Also, question for you. Is your middle man script automatic or do you have to run something locally before it updates and pushes up? So like, do you have middle man running somewhere keeping track of
master or do you execute it locally?