hi SM,

On 2 Sep 2013, at 17:19 , S Moonesamy <sm+ietf@elandsys.com> wrote:

> Hi Brian,
> At 03:34 02-09-2013, Brian Trammell wrote:
>> I'd like to second previous comments with regard to "slang", that such is merely a symptom of not communicating clearly: slang, higher- or lower-register speech, formal jargon designed to be impenetrable, etc, are all such symptoms, and we should try to address the cause rather than listing the effects. In my experience, network engineers as a class are not necessarily gifted with clarity, even in their own languages, but a reminder to try is certainly useful.
> 
> I'll highlight a point from the above:
> 
>  "jargon designed to be impenetrable"
> 
> Sometimes a person might be using the jargon because he or she sees other people doing it.  It might also be that it's easier (shorter way of expressing a thought).  Sometimes it might be because it won't be understood by a layman (see point above).

Here I was referring to a disease specific to academia where simple ideas are often disguised in math to make them look more impressive. Jargon designed to be precise is actually a good thing: there's a reason our documents have terminology sections. :)

> I agree that nowadays network engineers are not gifted with clarity even in their own language.
> 
> I proposed the following text to replace the sentence about slang:
> 
>   Native English participants attempt to accommodate the needs of other
>   participants by communicating clearly.

Tiny nit: the above reads a little ambiguously, and could be interpreted as referring to participants born in England, which is clearly not what you mean. It also absolves speakers of English as a second language from the responsibility of communicating clearly, which I hope is also not what you mean. Anecdotally years of working in a country where essentially everyone speaks English as a second language have taught me that ability to speak English and ability to communicate clearly in English are far less linked than I'd have originally thought.

I'd suggest "All participants attempt to accommodate the needs of others by communicating clearly, particularly those with English as a first language", instead.

Best regards,

Brian

>> There is one very important point though, that I think is missing from the draft, though it has been raised in the discussion:
>> 
>> The IETF operates on rough consensus.
>> 
>> From my viewpoint, this is probably the most important aspect of IETF culture (especially as it differs from many other engineering cultures), and should probably be made more central to point 3 than it is now. Indeed, the word consensus only appears in the introduction of revision -01,
>> 
>> There are sound technical reasons behind this aspect of the culture: briefly, systems designed by committees where every member has an effective veto -- "complete consensus" processes -- tend to be overly complex and to compromise on technical requirements where they shouldn't, and therefore difficult or practically impossible to implement correctly. On the other end of the spectrum, "single architect" systems tend to be more coherent (at least within the limits of the abilities of the architect), but can suffer from the limited viewpoint of the single architect and tend to have less thorough review. We've evolved something in the middle, and it seems (to me, anyway) to work well: we get the quality of review of many technically skilled people that comes with good committee processes, while avoiding the complexity and compromise inherent in complete consensus.
> 
> Agreed.
> 
>> All the subparts of point 3 are important - especially "we're looking for the best solution for the whole Internet, not just... for any particular...". However, this is partially at odds with rough consensus, in that rough consensus building does require compromise and often involves arbitrary choice among equally-good options. Holding out for "the best solution" here seems to invite precisely the blocking of the process that rough consensus is designed to avoid.
> 
> Agreed.
> 
> The above is insightful.
> 
>> I'd suggest the following text for point 3 (also de-emphasizing scale, which is important but perhaps a little out of scope here IMO.)
>> 
>> NEW:
>> 
>> 3. IETF participants devise solutions for the Internet that meet the needs of diverse technical and operational environments.
>> 
>> The goal of the IETF is to maintain and enhance a global Internet, and the problems we encounter are genuinely very difficult.  IETF participants use their best engineering judgment to work toward consensus for the best solution for the whole Internet, balancing the technical concerns of all participants, not just the best solution for any particular network, technology, vendor, or user.  We understand that "scaling is the ultimate problem" and that many ideas that seem workable at smaller scales fail this crucial test.
> 
> I like the text you suggested.  I'll add it to my working copy.
> 
> Regards,
> S. Moonesamy 
> _______________________________________________
> diversity mailing list
> diversity@ietf.org
> https://www.ietf.org/mailman/listinfo/diversity