Re: Diversity of candidates was Re: NomCom 2020 Announcement of Selections

[Keith Moore <[e-mail]>]

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