I had a similar problem loading the page on Firefox for desktop with private browsing. It turns out service workers don't work in private browsing, which it seems Bene (the software rendering the page) requires. Switching to a normal Firefox window solved the problem.
I don't know about other distros, but Debian makes it extremely easy to download both the binary package and the source package. For instance, on the page for the jq package [1], you can download the source using the links down the right-hand side, which includes the full test suite. The key, in my view, is that Debian has a nice way to associate both the final output artefact and the source (both the original source and their patches) with a specific version.
For packages where I don't include tests, I've had at least one downstream distro maintainer request that I include tests, since at least some of them treat npm or PyPI or whatever as the source of releases.
For packages where I do include tests, I've had at least one user request that I remove tests so that the footprint of the Docker image they're building is smaller.
Both are entirely reasonable requests, but package repositories don't really provide a good way of accommodating both at the same time, for instance, by allowing a separate upload of the dev gubbins such as tests.
Reminds me of the four types of documentation that sometimes get listed: tutorials, how-to guides, technical reference and explanation. (Usual caveat of all models are wrong but some are useful.) https://documentation.divio.com/
My (perhaps overly simplistic) take would be that we should take the thinking we use on the product itself (Who's going to use it? In what context? What would they already know? And so on), and apply and adapt it to the docs as we would any other product.
To expand on listening to your gut instinct: I find taking a "trust but verify" approach useful. Take the time to dig into what your instinct is telling you, try to match it up in words to your hiring criteria (which should go beyond technical stuff, including capturing whether or not you'd want to work with the person), and compare against other candidates to check you're being consistent. For instance, you don't want to unfairly penalise someone for being loquacious just because their interview was right before lunch and you were getting hungry, whereas you enjoyed interviewing the similarly talkative candidate that happened to be interviewed just after lunch.
I GM an online TTRPG, and I wanted to replicate the experience of the players drawing the map themselves as they go along. We use Roll20, but didn't find the tools particularly well suited to updating the map in the moment.
So, I had a go at making a little tool that lets you quickly make rough sketches of the map, as well letting you move tokens (for the characters) around. It's not particularly fancy, but it seems to work for us!