The main effect of the bot postings on me is actually to tell me that I have made rather fewer posts on the list than I had thought.
The good news is that there will be 10% less PHB in Prague than at previous IETFs.
Looking at the thread, I see a lot of bike shedding if not an actual editor war. I think it would be useful if all sides took a step back and recognized that mailing lists are a 40 year old technology and we have to expect them to be sub-optimal for 21st century needs.
The choice the IETF faces is this: Either stick to a vintage technology that does the job with some inconveniences and limitations or replace it with something designed to be fit for purpose and suffer the inevitable consequences of using a prototype.
Error 33: Don't build research on research. We didn't use the Web to design the Web, we used a mailing list. It is very clear that there is something missing in the social media/collaboration space that is not filled by current technologies. Perhaps we can find someone with some grad students interested in developing something that might fit.
Some requirements:
1) Finding material you need
I utterly despise Slack because the context scrolls off the top of the screen. Mailing lists and Facebook have the same problem but to a more limited degree. Conversations keep looping round as new members ask the same old questions. The solution that evolved in USENET was the FAQ, some of which have evolved into encyclopedic Web sites (e.g. talk.origins).
The best current solution is to have parallel mailing lists and Wikis but that doesn't work unless there is an individual willing to put in the considerable time and effort to bridge the gap and keep the wiki up to date.
Years ago, while planning to build my Star Trek Captains Chair, I made a Google Doc out of the threads on Dewback wing. Almost ten years later, about to actually start my build I asked if anyone had plans and received a PDF of my own hastily assembled doc described as 'The Build Manual'.
2) Security
Don't need end to end encryption for (most) IETF work but it is essential for collaboration inside the enterprise. Security of Data At Rest has to be built into the platform.
And it turns out that if you start making use of append only logs, encrypting data at rest is essential even for open forums like IETF because otherwise someone can perform a DoS attack by sending ransomware or child abuse to append to the chain.
3) Choosing constraints
One of the editor wars here is the use of HTML in email. My position is that HTML/2.0 is entirely suitable for email and anything later is absolutely not.
The ability to introduce some structure into messages is useful. The ability to highlight text with bold and underline is useful. But no, you the author do not get to decide that I read your message in fluorescent pink on green or choose the font and especially not the font size.
There is a group at MIT working on something might be relevant. Perhaps I will put in for a HotRFC.
