Oddbean

i personally hit this problem not expecting that i had to json-escape strings in tags because all the ones i was familiar with were human typed text and hex strings nope, zaps have embedded json in tag fields and this kind of unclear nonsense is rife through the whole thing

One more thing Write coding guidelines for the specs. Then rewrite all existing specs to match them, as close as possible. Then you don't have to have senior engineers saying "No json in the content field" or "make sure to use asciidoc or markdown compatible with asciidoc" to every new entrant.

yes, coding guidelines help a lot i have some unusual preferences in that for my own projects because i get intensely curious about neat things i see... like, almost nobody else except a few smart guys know that you can do one line functions in Go, or that you can break lines after dot operators, and my current little thing is using a script to drop a "common" file into every package that gives you lots of handy type aliases and a few common functions that you can update just by changing one version and running a script like, why would i type []byte when i could just use B and in local scopes, who uses B anyway? that's an exported variable name, in a local scope? yes! that's the point, you aren't going to mistake it and why write []byte when you can write B! it also injects loggers and such into the code, and honestly i think it would be a great feature in Go if you could write one file at the root of a repo that automatically is part of every package for this kind of stuff, it's not a macro system, it's aliases, and the aliases make the code more readable and easier to type anyway, going off track, but JSON doesn't forbid JSON inside strings except that the quotes have to be escaped, pretty much, probably some shortcuts can be taken for this... as it is, i already experimented with this because tags are "free form" but there is a whole bunch of rigid structures defined and in many cases they use hex encoding which is automatically double the binary version and for runtime why the fuck deal in encodings when you match faster on the binary and if the binary is what your database uses??? but it's work that i'm doing because of my own personal distaste for convention and love of elegance and conciseness in my own work, this leads to me recognising bugs in my code faster because i spend less time ignoring fluff and more time actually understanding the code there is some hilarious morons who like to chant "the code is the documentation" but you read their code and it's like reading beat poetry, good luck making sense of it, and the time it takes for the compiler to turn it into assembler... that's a big hint that the code is unclear

detriments are very clear just saw one today experienced several personally (the way the zaps have escaped text in them for zaps, notably) you want to all run off building code but don't want someone to keep track of your protocol designs and architectures? do you actually really not want anyone to come along and help? or is it in your mind that anyone new coming in is a hostile element to be fought against? then obviously we need a small team of moderators keeping the data and impartially maintaining this separation and acting as adjudicators and documenting the state of it let's say, like court secretaries because having the judges be the prosecution at the same time is pretty uncredible