And that's still too much "asking permission", to me. We're working on increasingly obscure and niche OtherStuff implementations and I don't see why I have to give someone who has nothing to do with our project veto-rights over biomedical vector analysis or CAN bus communications or refrigerant logistics, etc. We're the experts. That's why we're building the implementation. 🤷‍♀️ And it starts lower down. Why do I need to discuss a publishing spec with people who aren't experienced with publishing or internal auditing? If they were experienced in publishing or internal auditing, they would be writing the spec. What does their approval even mean? Are they checking for typos?

Do you want more administrative overhead or less? If you want someone to "watch" pages that can be done on the NIPs repo (again, wiki software is better, but not essentially different). But this is a massive increase in overhead. The NIPs repo contributors aren't there to debate ideas (although that happens too), just to vet whether a NIP has the requisite number of implementations, and merge corrections. This is a pretty lightweight role, but still quite taxing. If you want a permissionless wiki, then use the one that currently exists at wikifreedia. No one is stopping you. In fact, fiatjaf drafted https://github.com/nostr-protocol/nips/pull/1214, and to my knowledge I'm the only one so far who has published a NUD there. But this presents the opposite problem of potentially too little curation. I'm all for trying it, because forks are cool, but I'm not convinced it will be easier to navigate or more useful than the NIPs repo.