Vote Result Preprocessor

[qedi-r]

Some background: I initially thought this would be required to build the other PR I am submitting, but in the end it ended up simpler than intended. However, in this case, for the results, it greatly simplified the templates, and is a more natural pattern for pre-processing the csv for anything more complex in the future, so I think it is worth including.

[pnijjar]

My understanding is that Github pages does not permit custom plugins? I have a weak preference for doing the computations in Jekyll even though it is uglier. I liked your previous approach. It reduces the cognitive load for somebody who has to look at the codebase again in four years. But if you think an auxiliary script will be necessary and can make it work on Github pages then I can merge it in. My guess is that you will have to modify the Github Actions to incorporate the script, but I don't know.

From: https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll/about-github-pages-and-jekyll GitHub Pages cannot build sites using unsupported plugins. If you want to use unsupported plugins, generate your site locally and then push your site's static files to GitHub.

Also on: https://jekyllrb.com/docs/plugins/installation/

…

GitHub Pages is powered by Jekyll. All GitHub Pages sites are generated using the --safe option to disable plugins (with the exception of some whitelisted plugins) for security reasons. Unfortunately, this means your plugins won't work if you’re deploying via GitHub Pages. You can still use GitHub Pages to publish your site, but you'll need to either build the site locally and push the generated files to your GitHub repository or use GitHub Actions to host source files on GitHub yet build and deploy with full control on GitHub Pages.

[pnijjar]

I like the basic idea. In the writeups, I am uncomfortable with the "What can I ask candidates about" sections. It comes across as non-neutral advocacy. I agree that we can look at the wording for the other parts. I am not seeing a Ruby preprocessor in this PR? I am also seeing a lot of changes in `hide-listings.js` . From a selfish perspective I would prefer if those changes were split out into a different PR. I am also making changes to this file and they are going to clash with the changes you made (partially because we are doing similar things). Also: is your IDE doing a lot of style changes (removing whitespace, changing quote types) or are you doing this manually? (Apologies for just commenting and not committing my code. I realize that this is holding things up.)

[qedi-r]

Oh, shoot. Well, if GH pages doesn't support the plugin, we can put a pin on it for now. I'll investigate if we can do more with actions or not.

[qedi-r]

FWIW, building with GH Actions would execute the preprocessor. I think it's easier to manage, easier to read and write, but also it's just a marginal improvement.

Like I said, I thought it would get complex for the tags, but really, it wasn't. Vote counting and sorting is probably the most complex we have, mainly because of the re-ordering.