On Thu, Sep 27, 2018 at 07:25:29PM +0000, Mallory Knodel wrote: > I would argue the IETF is a lot more like a community or movement than > it is like a car company. Community. It's not a political or cultural movement at all. It is decidedly not like a car company. > Since consensus on protocols across a wide and growing technical > community is the goal, diversity is a key element of that. So if we’re > not succeeding at community diversity, we’re not succeeding. Period. > (To steal the punchline in Alix’s post). [I'm assuming that 'diversity' here means diversity of racial, ethnic, and national make-up of the community, as well as diversity of sexual orientation, sex / gender identification, and so on. I specifically assume that diversity of technical background of participants is not in scope.] We, IETF participants, are mostly self-selected. That is, we each have some personal motivation to participate, and so we do. Many of us participate in part because our employers want us to, but even so, we're often self-selected anyways in that we sought or developed positions where we are expected to participate in the IETF, or we sought management approval of our participation. Others of us are consultants and participate on behalf of customers. Yet others are participants independent of compensation by any third parties. Some participants are remote-only, thus making it difficult to observe their diversity. The IETF does not choose its participants. Its participants are the ones choosing to participate in the IETF. Thus it is difficult to see what policies the IETF could adopt that might increase participant diversity. The IETF does choose its officers (using the term loosely), such as IESG members. Any claims of illegal discrimination in this should be addressed immediately, of course. There are basically only four policies I can think of that might have an effect on IETF participant diversity: - targeted advertisement for participants - selective exclusion of participants - ask employers to help by doing one, the other, or both of the above - ask non-diverse participants to consider self-exclusion I'll note that normally we only exclude participants for cause. I doubt existing participants are keen to self-exclude in order to increase the diversity of the remaining community. That doesn't leave a lot of options. Perhaps an expert can propose other possible policies? I would say that we are in fact quite diverse, in at least one way: we're a very international community because a) we are a very technical community that attracts interest from companies and individuals in many countries, b) we work hard to host meetings outside the U.S. and Canada. We have participants from many countries. Some of us who participate from the U.S., are ourselves diverse in a variety of ways, such as being immigrants, for example. Has the Internet Society/IAOC/IAB/IESG/IRTF/IETF studied the diversity of these communities? Have there been surveys or censuses of IETF participants? Have we identified specific axes of diversity where we're coming up short? How are such things being measured? Is there an RFC setting out yardsticks for measuring IETF diversity? How do we measure the diversity of remote-only participants? Is there any data available on these matters? I, for one, have never been surveyed as an IETF participant. Nor have I ever heard of a survey of IETF participant diversity. I assume we have no data as to our diversity. Can you confirm this? If so, perhaps we should strice to acquire such data. We do seem to be more diverse today that in years past, though that would be a subjective and personal assessment given the lack of hard data; others might disagree. Yet I would not say that the IETF has failed in the past for having been less diverse than it is today, and I would not blame any technical failures on the IETF not being diverse enough, unless the only thing we consider when referring to IETF successes/failures is participant diversity (in which case see above commentary about the community's self-selection nature). To quote you again: > Since consensus on protocols across a wide and growing technical > community is the goal, diversity is a key element of that. [...] How is diversity a key element of technical success? Did TCP/IP fail because its authors were not diverse? Or did TCP/IP succeed in spite of its authors' [presumptive!] lack of diversity? Or are we talking about something other than the success of our protocols? I wouldn't say that "consensus on protocols ..." is "the goal". Consensus is a *tool* by which we develop protocols. As such consensus is a goal during development. But ultimately, the protocols -or perhaps their functionality- alone are the goal. The community itself is also a goal, of course, because it is a means to the end producing more/better Internet protocols, and because many of us derive personal pleasure from the community and our participation in it. I would agree -who wouldn't?!- that a community should be welcoming, friendly, non-discriminatory, and aware of biases, which should hopefully lead to a diverse community (though again, being self-selected, there can be no guarantee of this). In particular, no one should fear participating in the IETF! But I would be very careful of implying that a) we're not diverse [enough], and b) we're failing to produce successful protocols because of (a). (a) requires hard _data_, and (b) need not follow from (a). Now, if you'd said that we should have inclusivity as a goal, I would agree. And if you could point to ways in which we're not inclusive, I would agree that must address those issues. Absolutely, no doubt. And if you wanted us to pursue reasonable, non-exclusionary policies to perhaps increase our diversity, I would approve wholeheartedly. We don't have to believe that lack of diversity implies failure of our technical products in order to develop a more welcoming community (assuming it isn't already). I think we'll all agree work on making our community as welcoming as possible without having to believe that it is a fundamental prerequisite of protocol design and writing technical documents. Thanks, Nico --
