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.