Staying on the same thread (so those who've muted can retain their sanity), but resetting a bit...
Instead of welcoming new ideas and new ways of working into the milieu, and expressing appreciation that others want to put in effort to contribute to this shared venture, you and others are suggesting we micromanage the terms of engagement. First of all, perhaps you don't realize that we old folks are not going to be calling the shots forever and shouldn't be able to cast our preferences in high-pressure concrete. Frankly, either we meet new participants halfway, or the IETF becomes irrelevant as more welcoming forums take over new work. Based on what I'm seeing, maybe that would be for the best.
But more importantly, I think this whole conversation is focused on the wrong problem. Rough consensus is a tool, and "rough" is an important part of its description. If you endeavor to design a process to look like a wire protocol, you will fail because human interactions don't work that way. In the legal arena, this is expressed as "hard cases make bad law." Throwing up process impediments in a vain effort to make sure bad documents don't ever get published will also result in good documents not being published, and participants becoming discouraged and going elsewhere.
A successful standards process that admits open participation will necessarily be agile: iterative and based on frequent stakeholder engagement and fast feedback. *That* is where effort improving the IETF working model needs to be focused. Instead of trying to rule-make our way to ensuring you and everyone else is handed an opportunity to get the last word in on every change, document authors and WG chairs need to work to identify a representative set of stakeholders for each standards effort and make sure those stakeholders are engaged continuously in the iterative process of requirements gathering, design, build, test, and feedback. That's hard work because it requires a level of sustained attention and effort that goes way beyond monitoring a mailing list.
I assert, simply based on my observations over the past several years, that many participants are unwilling to put in this kind of sustained effort, and so they advocate for gates, control points, and convenience *for them* so they don't need to pay close attention while still not missing anything. This is absurd and frankly ass-backwards. If you want a say, you should be prepared to pay close attention, and that means going to where the work is rather than expecting it to come to you.
Kyle
On Fri, Jan 8, 2021 at 11:03 AM Wes Hardaker <wjhns1@xxxxxxxxxxxxx> wrote:
Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> writes:
> That is irrelevant. I use Git all the time for the purpose for which
> it is designed - managing source code. I do not use it as a process
> driven collaboration tool because it is not at all well designed for
> that except within the very narrow focus of managing and tracking
> code.
More specifically, github is designed around tracking and managing
things (not just code) that have very little subjectivity in what is
being tracked. Issue 5 is created because code is failing a test or
feature and needs to be fixed. Though there may be fights over the
right way to implement a feature, or whether spaces and tabs are used,
they're short lived and in the end most decisions in things that end up
in git are objectively measurable as to whether an issue should be
closed.
That's not true for IETF discussions where there are huge amounts of
back and forths, and restatements, and a lot of objectivity in the
discussions. That's where issue trackers will break down the most.
--
Wes Hardaker
USC/ISI
