> > Or maybe we postpone spending energy on new lists and tooling -- > both of which tend to create inertia for keeping “experiments” Wow. I’ll shut up now, but not before pointing out the absurdity. The original proposal by the IESG, as agreed to by the other streams, was a simple stopgap measure to obtain additional transparency in the AUTH48 process by an absolutely minimal amount of procedural and technical change. Create a mailing list, start adding that to the RFC editor AUTH48 mails. Can be implemented (business sense) in an afternoon, can be stopped in an afternoon if it breaks in unexpected ways. Beautiful engineering, and something that doesn’t need to be flogged to death (also because it already is agreed). Those of us that have been using the AUTH48 process for a couple decades now know that we need to improve the process on at least two major fronts: 1 — giving the authors and the other process participants better tools, in particular a way to continue to work on AUTH48 with the same tooling that was used in the WG and IESG segments of the document development (git and GitHub, domain-specific automation, authoring tools). 2 — giving the WG a better stance in the process, without derailing the process by encouraging relitigating WG dissent during the completion of an approved document (and without creating further process steps that impede the improvements usually provided by the RFC editing process from approved document to RFC). Yes, we should work on these work items in the new structure we are now creating. These will be multi-year processes, not the least because it will be hard to achieve continuous improvement in a structure that favors turning everything into grand endeavors. Which is a great reason to make a small continuous improvement step now. And, by the way, the stopgap would actually be very useful in generating real-world data that can inform 2. Grüße, Carsten
