**Context:**
I'm coming from my cluelessly created {T254637}.
**Problem:**
Improve discoverability of source code: Reduce bus factor / risk when a maintainer is AWOL and nobody can inspect code who does not have access to the instance; allow more contributions by allowing to inspect code which is in public, hopefully end up with less cases of applying https://wikitech.wikimedia.org/wiki/Help:Toolforge/Abandoned_tool_policy etc.
**Proposal:**
Align a requirement for tools to provide a `toolinfo.json` file with the next Debian upgrade from Stretch (https://wikitech.wikimedia.org/wiki/News/Stretch_deprecation to be created some future day) to Buster ([cf. Jessie to Stretch in 2019/2020](https://wikitech.wikimedia.org/wiki/News/Jessie_deprecation) in {T232677}).
**Misc:**
* Might help define one of the checkmarks what makes a tool stable (cf. {T115650}): source code is public ([requirement anyway](https://wikitech.wikimedia.org/wiki/Help:Toolforge/Rules) but reality can bite).
* If we lived in a Git "filesystem" world, I'd propose a `pre-commit.hook` which checks for existence of a `toolinfo.json` file && that its field values are valid. If not, then refuse pushing. Not sure if that's socially acceptable though. And not sure what's feasible in a non-Git world where people might `scp` their stuff.
* Feel free to decline if this turns out to be a bad idea and/or if you can think of better approaches.
* Wondering if I should tag this with #Toolforge-standards-committee or not.