On 1/25/21 4:35 PM, Andrew Sullivan wrote:
On Mon, Jan 25, 2021 at 04:03:46PM -0500, Keith Moore wrote:
That sentence sounds more than a little bit hostile itself.
I would appreciate knowing why you think so.
The words "special" and "bespoke" are part of why - you're taking an
essentially arbitrary position in favor of certain tools and against
other tools, without any apparent support for your position other than
bias, and you claim to be making that argument in favor of diversity.
With respect to tooling, this should be a relatively easy test. Are
the "bespoke" tools easier to use than whatever tools we might be
using otherwise?
"Easier" is surely a matter of where one stands. The point that I was
making (and the only point I was trying to make) is that, if you want
a more-diverse set of people to join, making the barriers to
engagement as high as the IETF does through tools that are really
foreign to a lot of people will not help with that. Like github or
not (I do not), it is a tool that is familiar to a lot of people, and
the more one adapts workflow to things that are familiar to a lot of
people the more likely one is to attract such people. That's the
network effect in operation, which is of course something that
everyone who works in the IETF is familiar with.
Surely you've noticed that there's a lot of pushback against github from
people who aren't familiar with it and/or who don't think it's an
effective tool? If you bias IETF toward github users you're biasing it
against people who prefer other tools or other ways of working. IMO
that kind of bias doesn't serve a consensus-making organization that's
trying to be open to participation by anyone.
I'm also having a little trouble wrapping my head around that argument
because of my own experience. For the last 13 years I've worked for
dozens of different clients, and each one came with its own
constraints. I've had clients that insisted that I use Word and Excel
and some other abysmal MS drawing tool that I don't recall at the
moment. I've had other clients insisting that I use Jira and Bitbucket
which really make work much more difficult than it needs to be. I've
had clients insisting that I use Eclipse IDE or some vendor-specific
variant of that even when it constantly broke down, lost code, and
required reinstallation. I've had one client insisting that I use a
Windows box on my desk for a year until I finally got them to let me use
Linux, after which my productivity doubled. One of my current nemeses
is Slack, which is so much worse than email that it's criminal. Some
of these tools are better than others, but all of them are either
impediments to getting work done, or they come with baggage that creates
impediments to getting work done (like security holes big enough to
drive aircraft carriers through).
But all of these for me were simply business decisions. I could take
the gig and the money that went with it, or not. Most of my work these
days is from home, and I absolutely will not run Windows on bare metal
on my home network. But for enough money I can set up a VM and run it
there. Or I can buy a used X86 box, set up a completely isolated
network with its own Internet connection, and run it there. If I'm
being paid enough money I can buy licenses for the software I'm required
to use, or I can set up separate systems on separate networks so that
using whatever web site is hopefully only a minimal threat to my
privacy, security, or whatever. It's just business. I try to not
burden my clients with it, and I don't lose a lot of sleep over it.
(Actually there are two simple questions: (1) Would I be making enough
money for long enough to put up with this particular set of BS
constraints or not? and (2): Is life too short to be wasting my time
beating my head against the particular walls that this client insists
on? The older I get, the more the latter question becomes relevant,
and the more often the answer is "no".)
From my perspective, whether to use IETF's "bespoke" tools involves
approximately the same kind of questions. From my 30 years experience
in IETF I can state with tremendous confidence that the "bespoke" tools
are generally MUCH better than the ones that existed before.
(Otherwise they wouldn't have been either developed or adopted.) From
my experience with various tools used by several industry clients I can
state with a fair amount of confidence that the "bespoke" tools are
generally better than what most of the industry is using, but I can't be
certain that there's absolutely nothing better out there for every use
case. What I can say confidently is that there's no good reason to
exclude "bespoke" tools merely because they are "bespoke".
(Email, BTW, is not a "bespoke" tool; it's a very mature tool that is
informed by 50+ years of experience. It's very widely used in
industry. It's also MUCH better than the vast majority of other
messaging systems in use today, especially if you look at the full
spectrum of uses. It has tremendous portability, accessibility,
robustness and a wide variety of use cases. And since email basically
consists of protocols that IETF maintains, to the extent that email
isn't up to snuff we have a lot of power - and responsibility - to
improve it.)
***
Maybe there's another factor here, which is the learning curve for a new
tool versus the amount of time one expects to participate in IETF.
People prefer to use the tools to which they are accustomed. Learning
a new tool for some particular purpose takes time, and it's hard to
justify that time when one already knows how to use an existing tool for
that purpose. Also, once you become an expert in one tool, you'll
probably never be expert level in another tool that does more-or-less
the same thing.
But it's even harder for someone to justify the investment to learn new
tools required by a new client, or similarly by IETF, if someone sees
that activity as only a temporary diversion (or nuisance?) from what
they want to be doing. It used to be that IETF attracted long-term
participants; this seems less true today because so much current IETF
work is niche work. I'm not saying that this is inherently bad or good;
IETF clearly needs both long-term participants and people working on
protocols for niche cases.
I suspect that the discussions of "bespoke" tools would be more
productive if we were talking about specific tools, because each has its
own costs and benefits and its own learning curve. If new IETF
participants are cursing xml2rfc, I'm probably right there with them.
But most of our bespoke tools seem relatively easy to use. Rather than
attack "bespoke" tools in general, maybe look at each tool and see if it
really fits us well?
Beyond that, IMO we need to maximize the extent to which people can use
their preferred tools without requiring others to do so. And that means
defining our interfaces around standards
***
BTW, I don't think the biggest barriers to participation in IETF are the
bespoke tools, though I can understand the reluctance of newcomers to
use some of them. I don't even think the biggest barriers are dealing
with different peoples' personalities and different ideas of
"professionalism", partly because tolerance of different cultures and
different points of view is essential for IETF's work anyway. The
biggest barriers to me appear to be excessive bureaucracy (it's really
hard to keep track of which group, committee, organization or supporting
organization does what), and (related to this) the abysmally poor
organization of information of IETF's web site and other sources of
information (e.g. RFCs, IESG statements, etc.) about how IETF works.
Keith
