Kyle, I would like to find a technique that works for folks like me, and
works for new folks who are used to different paradigms. But the
suggestions that have been offered (like weekly digests) simply miss the
point. Maybe part of the problem is different assumptions about how
people engage at the IETF. I have at least a dozen WGs that I am
actively involved with, and probably twice as many that I try to watch
with enough attention and knowledge that a I can appropriately
participate when I need to. While I have a good memory, I rely on
context in the emails to help me manage that much variation. (And no, I
do not expect all of the context.)
No solution is perfect, and I am not asking that the next modification
to how we work be perfect for me or anyone else. But that does not mean
I should agree to things that are extremely unproductive for me or others.
Yours,
Joel
PS: While change and evolution is necessary, it seems to me that those
asking for changes need to justify and accommodate. The assumption that
we must use the current great thing does not seem appropriate.
On 1/8/2021 12:31 PM, Kyle Rose wrote:
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
<mailto:wjhns1@xxxxxxxxxxxxx>> wrote:
Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx
<mailto: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
