Yep. I bought a yellow one with the intention of making it a dedicated PICO-8 machine, and it is wonderful. It's not as perfect as 351p is for GBA, as 5x integer scaling leaves you with some unused screen space, but still, an absolute joy to play.
I wholeheartedly agree with you that TIC-80 is not as great as PICO-8 is, and I would never recommend it over PICO-8 to someone who wants to start their adventure with game development.
But it is not a clone of PICO-8. It offers a resolution that's very similar to that of the Game Boy Advance, so it serves as a nice transition stage towards GBA development. You can then enjoy your games on a console like Anbernic RG351P that's optimized for GBA games (2x integer scaling, same screen ratio). It's a specific use case, but one where TIC-80 shines.
That's just a single data point, but here's my experience. I have severe myopia, and I experience discomfort when reading from a screen over a prolonged period of time. I read a lot, and I can't read for more than two hours even on a quality LCD screen. With e-paper, three hours of continuous reading are not an issue. If my reading habits were as simple as reading for an hour before bedtime, I don't think I would need anything more than a tablet.
You pay for the console, and the games are open by design. You can load any pico game into the console, go into edit mode, and see / edit assets, music, levels. The console only supports lua, which gives you the advantage that every game you open to see the source code will be written in the same language. A wonderful little thing. I used it to introduce kids to game development with good results.
> my point is there are dozens of other convenient questions you can ask to filter out projects
Absolutely. And I agree with you that "Is it widely used in production?" is a better filter. But that does not diminish the value of the filtering done by "Is it properly documented?". After all, it's not like we're limited in the number of criteria we can use to filter out bad projects.
You're assuming someone places value on proper documentation because they need proper documentation to make it "accessible to you". That doesn't have to be the case.
For me, lack of proper documentation constitutes a red flag, and says something very negative about the project. The question "Is it properly documented?" serves as a simple and convenient way to filter out projects that have a low chance of being mature enough to fit my needs.
> My problem is, I know that we are missing information, what I don't know is how to tease out that information from myself and other coworkers.
I would start by reflecting on the way in which getting that knowledge out of the coworkers into the knowledge base is incentivized.
I keep my notes in markdown files. A lot of my coworkers use Obsidian, CherryNotes, OneNote, and I'm sure that there's a dozen other solutions out there. Keeping notes locally is actively encouraged by the fact you can't rely on the Confluence server to be up after business hours and the fact that the centralized knowledge base upgrades destroyed our documentation efforts twice over the past 10 years.
I also keep my notes short, omitting everything that's obvious to me. This makes them less valuable when it comes to knowledge sharing, but makes them better for me - short notes mean less visual noise to filter out. Writing a version of those notes that's more comprehensive is extra effort. That extra effort needs to be visible, treated as 'real work', encouraged and valued. Otherwise, I will prioritize other tasks that are visible, treated as 'real work', encouraged and valued.
The first thing I would worry about is making sure the central knowledge repository is as convenient as the local notes. Then, I would examine if creating / updating documentation in the central repository is encouraged, and in what way.
I can provide answers to the last two questions, based on my limited experence.
> What are "local HR laws"?
I think this refers to the fact that regulatory compliance is different depending on where your business is located. Which brings me to my anecdotal experience with:
> What do you mean by "scaring employers re: regulatory compliance"? "Scaring" reads like you're implying some kind of manipulation, but "regulatory compliance" is something a company should already be in; what is there to fear?
A company I worked for was located in a country where it was the legal duty of the employer to keep track of the people on the office premises. Most companies used a time tracking system for this, the punch-in, punch-out kind. The thing is, the purpose of the regulation was to make sure that when evacuated, there is always a list of people that were in the building - so it could be referred to after the evacuation to see if everyone is accounted for. This law did not require keeping track of the time someone entered the premises, or the time someone left - the requirement could be satisfied with a simple paper list with checkboxes - one for when you enter, one for when you leave. And that's exactly what was done in this office. Every month or two, the company got an offer from a business trying to sell a time tracking appliance or service, and many, if not all of those offers were using manipulatory tactics - "If you're not using a time tracking system, you might be violating the law" was a common phrase. The manipulation here was that it was true that a system like that would satisfy the legal requirement, but the offers strongly implied that a having a system like that was necessary to satisfy the legal requirement. Which was not the case.