Re: Old directions in social media.

[Kyle Rose <[e-mail]>]

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 <[e-mail]> wrote:

> Phillip Hallam-Baker <[e-mail]> 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
>
>