One document matched: draft-crocker-diversity-conduct-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no"?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc inline="yes"?>
<?rfc topblock="yes" ?>
<?rfc autobreaks="yes" ?>
<rfc category="info" docName="draft-crocker-diversity-conduct-03" ipr="trust200902">
<front>
<title abbrev="Diversity & Conduct">An IETF with Much Diversity and Professional
Conduct</title>
<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<postal>
<street>675 Spruce Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>USA</country>
</postal>
<phone>+1.408.246.8253</phone>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<author fullname="Narelle Clark" initials="N." surname="Clark">
<organization>Pavonis Consulting</organization>
<address>
<postal>
<street>C/- PO Box 1705</street>
<city>North Sydney</city>
<region>NSW</region>
<code>2059</code>
<country>Australia</country>
</postal>
<phone>+61 412297043</phone>
<email>narelle.clark@pavonis.com.au</email>
</address>
</author>
<date day="" month="" year="2015"/>
<abstract>
<t>The process of producing today's Internet through a culture of open participation and
diverse collaboration has proved strikingly efficient and effective, and it is
distinctive among standards organizations. For its early years, participation in the
IETF and its antecedent was almost entirely composed of well-funded, American,
white, male engineers, establishing a distinctive and challenging group dynamic,
both in management and in personal interactions. In the case of the IETF,
interaction style can often demonstrate singularly aggressive behavior, often
including singularly hostile tone and content. Groups with greater diversity make
better decisions. Obtaining meaningful diversity requires more than generic good
will and statements of principle. Many different behaviors can serve to reduce
participant diversity or participation diversity. This paper discusses IETF
participation, in terms of the nature of diversity and practical issues that can
increase or decrease it.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Internet Engineering Task Force <xref target="IETF"/> grew out of a research
effort that was started in the late 1960s, with central funding by the US Department
of Defense Advanced Research Projects Agency (ARPA, later DARPA), employing a
collection of research sites around the United States, and including some
participation by groups of the US Military. The community was originally restricted
to participation by members of the funded research groups. In the 1980s,
participation expanded to include projects funded by other agencies, most notably
the US National Science Foundation for its NSFNet effort. At around the time the
IETF was created in its current form, in the late 1980s, participation in the group
became fully open, permitting attendance by anyone, independent of funding,
affiliation, country of origin, or the like.
<!--<list>
<t>(As an aside it might be worth noting that the first author was the first
commercial participant allowed to attend under this unrestricted model. Or rather,
my participation was initially allowed as an exception, due to my prior work
within the Arpanet community, but it created the precedent that required the IETF
to become fully open at the very next meeting. My own opinion is that the change
was inevitable and appropriate and the timing proper; by then it had become clear
that the Internet was quickly developing into an open, international service, and
the IETF was an essential venue for technical dialogue to facilitate that.)</t>
</list>--></t>
<t>Beyond the obvious effects of the resulting technology that we now enjoy, the process
of producing today's Internet through a culture of open participation and diverse
collaboration has proved strikingly efficient and effective, and it is distinctive
among standards organizations. This culture has been sustained across many changes
in participant origins, organizational structures, economic cycles, and formal
processes. However maintenance of the IETF's effectiveness requires constant
vigilance. As new participants join the IETF mix, it is increasingly easy for the
IETF's operation to gradually invoke models from other environments, which are more
established and more familiar, but are less effective.</t>
<t>Historically participation in the IETF and its antecedent was almost entirely
composed of well-funded, American, white, male engineers. No matter the intentions
of the participants, such a narrow demographic created a distinctive group dynamic,
both in management and in personal interactions, which persists into the current
IETF. Aggressive and even hostile discussion behavior is quite common. In terms of
management the IETF can be significantly in-bred, favoring selection of those who
are already well-known. Of course, the pool of candidates from which selections are
made suffer classic limitations of diversity found in many engineering environment.
Still there is evidence and perception of selection bias, beyond this.</t>
<t>In the case of the IETF, the style of interaction can often demonstrate singularly
aggressive behavior, including singularly hostile tone and content. In most
professional venues, such behavior is deemed highly unprofessional, or worse. Within
the IETF, such behavior has had long-standing tolerance. Criticizing someone's
hostility is dismissed by saying that's just the way they are, or that someone else
provoked it, and anyone expressing concern about the behavior is typically
admonished to get thicker skin.</t>
<t>As the IETF opened its doors to participation by anyone, its demographics have
predictably moved towards much greater variety. However the group culture has not
adapted to accommodate these changes. The aggressive debating style, and the
tolerance for personal attacks, can be extremely off-putting for participants from
more polite cultures. And the management selection processes can tend to exclude
some constituencies inappropriately.</t>
<t>In 2013, members of an informal IETF women's interest group, called "systers",
organized a quiet experiment, putting forward a large number of women candidates for
management positions, through the IETF's "Nomcom" process. Nomcom is itself a
potentially diverse group of IETF participants, chosen almost at random. Hence its
problematic choices -- or rather, omissions -- could be seen as reflecting IETF
culture generally.</t>
<t>Over the years some women have been chosen for IETF positions as authors, working
group chairs, area directors, Internet Architecture Board <xref target="IAB"/>
members and IETF Administrative Oversight Committee<xref target="IAOC"/> members.
However the results of the systers experiment were not encouraging. In spite of
their engineering a disproportionately high number of female candidates, not a
single one was selected. Although any one candidate might be rejected for entirely
legitimate reasons, a pattern of rejection this consistent indicates an
organizational bias. The results were presented at an IETF plenary and it engendered
significant IETF soul-searching, as well as creation of a group to consider
diversity issues for the IETF.<xref target="Div-DT"/><xref target="Div-Discuss"/>
Other activities around that same time also engendered IETF consideration of
unacceptable behaviors, generally classed as harassment. This resulted in a formal
IETF anti-harassment policy.<xref target="Anti-Harass"/>
</t>
<t>This paper discusses IETF participation, in terms of the nature of diversity and
practical issues that can increase or decrease it.</t>
<t><list>
<t><list style="hanging">
<t hangText="NOTE: ">This paper covers difficult topics that present
challenges for constructive discussion. Nonetheless, feedback is
eagerly sought to improve what it says and how it says it. The
suggested forum for this draft is the IETF's Diversity discussion list:<list>
<t><figure>
<artwork align="center">https://www.ietf.org/mailman/listinfo/diversity</artwork>
</figure></t>
</list></t>
</list></t>
</list></t>
</section>
<section title="Concerns">
<section title="Diversity">
<t>Diversity concerns the variability of a group's composition. It can reasonably
touch every conceivable participant attribute. It includes the usual range of
"identified class" attributes, including race, creed, color, religion, gender
and sexual orientation, but also extends along with all manner of beliefs,
behaviors, experiences, preferences and economic status.</t>
<t>Groups with greater diversity make better decisions. They perform better at
diverse tasks both in terms of quantity and quality and a great deal of research
has found that heterogeneity often acts as a conduit for ideas and
innovation.<xref target="Kellogg"/>,<xref target="WiseCrowd"/>,<xref
target="Horowitz"/> The implicit assumptions of one participant might not be
considerations for another, and might even be unknown by still others. And
different participants can bring different bases of knowledge and different
styles of analysis. The same people from the same education and experience will
all too readily bring the same ideas forward and subject them to the same
analysis, thus diminishing the likelihood for new ideas and methods to emerge,
or underlying problems to be noted.</t>
<t>However a desire to diligently attend to group diversity often leads to
mechanical, statistical efforts to ensure representation by every identified
constituency. For smaller populations, like the IETF and especially for small
management teams, this approach is counter-productive. First, it is not possible
to identify every single constituency that might be relevant. Second, the group
size does not permit representation by every group. Consequently, in practical
terms, legitimate representation of diversity only requires meaningful variety,
not slavish bookkeeping. In addition, without care it can lead to the negative
effects of diversity where decision making is slowed, interaction decreased and
conflict increased.<xref target="Horowitz"/></t>
<t>Pragmatically, then, concern for diversity merely requires serious attention to
satisfying two requirements:<list style="hanging">
<t hangText="Participant Diversity --">Decisions about who is allowed into
the group require ensuring that the selection process encourages varying
attributes among members.</t>
<t hangText="Participation Diversity --">Achieving effective generation of
ideas and reviews within a group requires ensuring that its discussions
encourage constructive participation by all members and that the views
of each member are considered seriously.</t>
</list>In other words, look for real variety in group composition and real
variety in participant discussion. This will identify a greater variety of
possible and practical solutions.</t>
<t>Obtaining meaningful diversity requires more than generic good will and
statements of principle. The challenges, here, are to actively:<list
style="symbols">
<t>Encourage constructive diversity</t>
<t>Work to avoid group dynamics that serve to reduce diversity</t>
<t>Work to avoid group dynamics that serve to diminish the benefits of
diversity</t>
<t>Remove those dynamics when they still occur</t>
</list> It also requires education about the practicalities of diversity in an
open engineering environment; and it requires organizational processes that
regularly consider what effect each decision might have on diversity.</t>
<t>Examples abound:<list style="symbols">
<t>Formally, an IETF working group makes its decisions on its mailing list.
Since anyone can join the list, anyone with access to the Internet can
participate. However working groups also have sessions at the
thrice-annual IETF face-to-face meetings and might also hold interim
meetings, which are face to face, telephonic, or video conferencing.
Attendance at these can be challenging. Getting to a face to face
meeting costs a great deal of money and time; remote participation often
incurs time-shifting that include very early or very late hours. So
increased working group reliance on meetings tends to exclude those with
less funding or less travel time or more structured work schedules.</t>
<t>Vigorous advocacy for a strongly-held technical preference is common in
engineering communities. Of course it can be healthy, since strong
support is necessary to promote success of the work. However in the IETF
this can be manifest in two ways that are problematic. One is a personal
style that is overly aggressive and serves to intimidate, and hence
unreasonably gag, those with other views. The other is a group style
that prematurely embraces a choice, and does not permit a fair hearing
for alternatives. </t>
<t>Predictably, engineers value engineering skills. When the task is
engineering this is entirely appropriate. However much of the IETF's
activities, in support of its engineering efforts, is less about
engineering and more about human and organizational processes. These
require very different skills. To the extent that participants in those
processes are primarily considered in terms of their engineering
prowess, those who are instead stronger in other, relevant skills will
be undervalued, and the diversity of expertise that the IETF needs will
be lost.</t>
<t>IETF standards are meant to be read, understood and implemented by people
who were not part of the working group process. The gist of the
standards also often needs to be read by managers and operators who are
not engineers. IETF specifications enjoy quite a bit of stylistic
freedom to contain pedagogy, in the service of these audience goals.
However the additional effort to be instructional is significant and
active participants who already understand and embrace the technical
details often decline from making that effort. Worse, that effort is
also needed during the specification development effort, since many
participants might lack the background or superior insight needed to
appreciate what is being specified. Yet the IETF's mantra for "rough
consensus" is exactly about the need to recruit support. In fact, the
process of "educating" others often uncovers issues that have been
missed.</t>
</list></t>
</section>
<section title="Harassment and Bullying">
<t>Many different behaviors can serve to reduce participant diversity or
participation diversity. One class of efforts is based on overt actions to
marginalize certain participants, by intimidating them into silence or
departure. Intimidation efforts divide into two styles warranting distinction.
One is harassment, which pertains to biased treatment of demographic classes. A
number of identified classes are usually protected by law and community
understanding that such biased behavior can not be tolerated has progressively
improved.</t>
<t>Other intimidation efforts are tailored to targeted individuals and are generally
labeled bullying.<xref target="Har-Bul"/>,<xref target="Video"/>,<xref
target="Signs"/>, <xref target="Escalated"/>, <xref target="Prevention"/>
The nature and extent of bullying in the workplace is widely underestimated,
misunderstood and mishandled. It is:<list>
<t>"...[B]ehavior directed at an employee that is intended to degrade,
humiliate, embarrass, or otherwise undermine their performance... [T]he
sure signs of a bully that signify more than a simple misunderstanding
or personal disagreement... might include: <list style="symbols">
<t>Shouting, whether in private, in front of colleagues, or in front
of customers</t>
<t>Name-calling</t>
<t>Belittling or disrespectful comments</t>
<t>Excessive monitoring, criticizing, or nitpicking someone's
work</t>
<t>Deliberately overloading someone with work</t>
<t>Undermining someone's work by setting them up to fail</t>
<t>Purposefully withholding information needed to perform a job
efficiently</t>
<t>Actively excluding someone from normal workplace/staff room
conversations and making someone feel unwelcome"<xref
target="wikiHow"/></t>
</list>
</t>
<t>"Perhaps the most easily recognizable Serial Bully traits are: <list
style="symbols">
<t>Jekyll and Hyde nature — Dr Jekyll is 'charming' and
'charismatic'; 'Hyde' is 'evil'</t>
<t>Exploits the trust and needs of organizations and individuals,
for personal gain</t>
<t>Convincing liar — Makes up anything to fit their needs at
that moment</t>
<t>Damages the health and reputations of organizations and
individuals</t>
<t>Reacts to criticism with Denial, Retaliation, Feigned Victimhood
<xref target="Defensive"/>, <xref target="MB-Misue"/></t>
<t>Blames victims</t>
<t>Apparently immune from disciplinary action</t>
<t>Moves to a new target when the present one burns out "<xref
target="Bully-Ser"/></t>
</list></t>
</list></t>
<t>Whether directed at classes or individuals, intimidation methods used can: <list
style="symbols">
<t>Seem relatively passive, such is consistently ignoring a member</t>
<t>Seem mild, such as with a quiet tone or language of condescension</t>
<t>Be quite active, such as aggressively attacking what is said by the
participant</t>
<t>Be disingenuous, masking attacks in a passive aggressive style</t>
</list> If tolerated by others, and especially by those managing the group,
these methods create a hostile work environment. <xref target="Dealing"/><list>
<t>When public harassment or bullying is tolerated, the hostile environment
is not only for the person directly subject to the attacks.</t>
<t>The harassment also serves to intimidate others who observe that it is
tolerated. It teaches them that misbehaviors will not be held
accountable.</t>
</list></t>
<t>The IETF's Anti-Harassment Policy <xref target="Anti-Harass"/> uses a single term
to cover the classic harassment of identified constituencies, as well as the
targeted behavior of bullying. The policy's text is therefore comprehensive,
defining unacceptable behavior as "unwelcome hostile or intimidating behavior."
Further it declares: "Harassment of this sort will not be tolerated in the
IETF." An avenue for seeking remedy when harassment occurs is specified as a
designated Ombudperson. </t>
<t>Unified handling of bullying and harassment corresponds to policies in other
organization, such as <list>
<t><list style="hanging">
<t hangText="Facebook: ">Community Standards <xref
target="F-H-Cybul"/></t>
<t hangText="LinkedIn: ">"Be Nice" in LinkedIn Professional
Community Guidelines <xref target="L-H-Cybul"/></t>
<t hangText="Youtube: ">Harassment and cyberbullying <xref
target="Y-H-Cybul"/></t>
</list></t>
</list></t>
<t>However the IETF has a long history of tolerating aggressive and even hostile
behavior by participants. <list>
<t>So this policy signals a formal and welcome change. The obvious challenge
is to make the change real, moving the IETF from a culture that
tolerates -- or even encourages -- inter-personal misbehaviors to one
that provides a safe, professional, and productive haven for its
increasingly-diverse community. </t>
</list></t>
<t>Here again, examples abound, to the present:<list style="symbols">
<t>Amongst long-time colleagues, acceptable interpersonal style can be
whatever the colleagues want, even though it might look quite
off-putting to an observer. The problem occurs when an IETF participant
engages in such behaviors with, or in the presence of, others who have
not agreed to the social contract of that relationship style and might
not even understand it. For these others, the behavior can be extremely
alienating, creating a disincentive against participation. Yet in the
IETF it is common for participants to feel entitled to behave in overly
familiar or aggressive or even hostile fashion that might be acceptable
amongst colleagues, but is destructive with strangers.</t>
<t>The instant a comment is made that concerns any attribute of a speaker,
such as their motives, the nature of their employer, or the quality of
their participation style, the interaction has moved away from technical
evaluation. In many cultures, all such utterances are intimidating or
offensive. In an open, professional participation environment, they
therefore cannot be permitted. </t>
<t>As a matter of personal style or momentary enthusiasm, it is easy to
indulge in condescending or dismissive commentary about someone's
statements. As a discussion technique, it is a technique for reducing
the target's influence on the group. Whether non-verbal, such as rolling
one's eyes; paternalistic, such as noting the target's naivete; or
overtly hostile, such as impugning the target's motives, it is an
attempt to marginalize the person rather than focus on the merits of
what they are saying. It constitutes harassment or bullying.</t>
</list></t>
</section>
</section>
<section title="Constructive Participation">
<t>The goal of open, diverse participation requires explicit and on-going organizational
effort to ensure that it happens for access, engagement and facilitation.</t>
<section title="Access">
<t>Aiding participants with access to IETF materials and discussions means that it
is easy for them to:<list style="symbols">
<t>Know what exists</t>
<t>Find what is of interest</t>
<t>Retrieve documents or gain access to discussions</t>
<t>Be able to understand the content</t>
</list></t>
<t>After materials and discussions are located, the primary means of making it easy
to access the substance of the work is for statements to be made in language
that is clear and explanatory. Writers and speakers need to carefully consider
the likely audience and package statements accordingly. This often means taking
a more tutorial approach than one might naturally choose. In speech, it means
speaking more deliberately, a bit more clearly and a bit more slowly than one
needs with close collaborators. When language is cryptic or filled with
linguistic idiosyncrasies and when speech is too fast, it is dramatically less
accessible to a diverse audience.</t>
</section>
<section title="Engagement">
<t>Once content is accessible, the challenge is to garner diverse contribution for
further development. Engagement means that it is easy for constructive
participants to be heard and taken seriously through constructive
interaction.</t>
<t>Within the IETF, the most common challenge is the choices participants make in
the way they respond to comments. The essence of the IETF is making proposals
and offering comments on proposals; disagreement is common and often healthy...
depending upon the manner in which disagreement is pursued. </t>
</section>
<section title="Facilitation">
<t>In order to obtain the best technology, the best ideas need first to be
harvested. Processes that promote free ranging discussion, tease out new ideas,
and tackle concerns should be promoted. This will also run to: <list
style="symbols">
<t>Encouraging contributions from timid speakers</t>
<t>Showing warmth for new contributors</t>
<t>Preventing dominance by, or blind deference to, those perceived as the
more senior and authoritative contributors</t>
<t>Actively shutting down derogatory styles</t>
</list></t>
<t>It is important that participants be facilitated in tendering their own ideas
readily so that innovation thrives.</t>
</section>
<section title="Balance">
<t>There is the larger challenge of finding balance between efforts to facilitate
diversity versus efforts to achieve work goals. Efforts to be inclusive include
a degree of tutorial assistance for new participants. They also include some
tolerance for participants who are less efficient at doing the work. Further,
not everyone is capable of being constructive and the burdens of accommodating
such folk can easily become onerous.</t>
<t>As an example, there can be tradeoffs with meeting agendas. There is common
push-back on having working group meetings be a succession of presentations. For
good efficiency participants want to have just enough presentation to frame a
question, and then spend face-to-face time in discussion. However "just enough
presentation" does not leave much room for tutorial commentary to aid those new
to the effort. Meeting time is always too short, and the primary requirement is
to achieve forward progress.</t>
</section>
<section title="IETF Track Record">
<t>The IETF's track record for making its technical documents openly available is
notably superb, as is its official policy of open participation in mailing lists
and meetings. Its track record with management and process documentation is more
varied, partly because these cover overhead functions, rather than being in the
main line of IETF work and, therefore, expertise. So they do not always get
diligent attention. Factors include the inherent challenges in doing management
by engineers, as well as challenges in making management and process documents
usable for non-experts and non-native English speakers.</t>
<t>On the surface, the IETF's track record for open access and engagement therefore
looks astonishingly good, since there is no "membership", and anyone is
permitted to join IETF mailing lists and attend IETF meetings. Indeed, for those
with good funding, time for travel, and skills at figuring out the IETF culture,
the record really is excellent.</t>
<t>Very real challenges exist for those who have funding, logistics or language
limitations. In particular, these impede attendance at meetings. Another
challenge is for those from more polite cultures who are alienated by the style
of aggressive debate that is popular in the IETF. </t>
</section>
<section title="Avoiding Distraction">
<t>For any one participant, some other participant's contributions might be
considered problematic, possibly having little or no value. Worse, some
contributions are in a style that excites a personal, negative reaction.</t>
<t>The manner chosen for responding to such contributions dramatically affects group
productivity. Attacking the speaker's style or motives or credentials is not
useful, and primarily serves to distract discussion from matters of substance.
Among the many possible ways to pursue constructive exchange, in the face of
such challenges, guidance includes: <list style="symbols">
<t>Ignore such contributions; perhaps someone else can produce a productive
exchange, but there is no requirement that anyone respond.</t>
<t>Respond to the content, not the author; in the extreme, literally ignore
the author and merely address the group about the content. </t>
<t>Offer better content, including an explanation of the reasons it is
better.</t>
</list> The essential point here is that the way to have a constructive exchange
about substance is to focus on the substance. The way to avoid getting
distracted is to ignore whatever is personal and irrelevant to the
substance.</t>
</section>
</section>
<section title="Responses to Unconstructive Participation">
<t>Sometimes problematic participants cannot reasonably be ignored. Their behavior is
too disruptive, too offensive or too damaging to group exchange. Any of us might
have a moment of excess, but when the behavior is too extreme or represents a
pattern, it warrants intervention.</t>
<t>A common view is that this should be pursued personally, but for such cases, it
rarely has much effect. This is where IETF management intervention is required. The
IETF now has a reasonably rich set of policies concerning problematic behavior. So
the requirement is merely to exercise the policies diligently. Depending on the
details, the working group chair, mailing list moderator, Ombudperson or perhaps
IETF Chair is the appropriate person to contact.<xref target="MlLists"/>,<xref
target="Anti-Harass"/></t>
<t>The challenge, here, is for both management and the rest of the community to
collaborate in communicating that harassment and bullying will not be tolerated. The
formal policies make that declaration, but they have no meaning unless they are
enforced.</t>
<t>Abusive behavior is easily extinguished. All it takes is community resolve. </t>
</section>
<section title="Security Considerations">
<t>The security of the IETF's role in the Internet community depends upon its
credibility as an open and productive venue for collaborative development of
technical documents. There is strong potential benefit to technical documents
through an increase in rigor arising from more diverse scrutiny. The potential for
future legal liability in the various jurisdictions within which the IETF operates
also indicates a need to act to reinforce behavioral policies with specific
attention to workplace safety.</t>
</section>
</middle>
<back>
<references title="References - Normative">
<reference anchor="Anti-Harass">
<front>
<title>IETF Anti-Harassment Policy</title>
<author>
<organization>IETF</organization>
</author>
<date year="2013"/>
</front>
<seriesInfo name="WEB"
value="http://www.ietf.org/iesg/statement/ietf-anti-harassment-policy.html"/>
</reference>
<reference anchor="MlLists">
<front>
<title>IESG Guidance on the Moderation of IETF Working Group Mailing
Lists</title>
<author/>
<date/>
</front>
<seriesInfo name="WEB"
value="https://www.ietf.org/iesg/statement/moderated-lists.html"/>
</reference>
</references>
<references title="References - Informative">
<reference anchor="Dealing">
<front>
<title>Dealing with Workplace Bullying: A practical guide for employees</title>
<author
fullname="Interagency Round Table on
Workplace Bullying, South Australia"/>
<date/>
</front>
<seriesInfo name="WEB"
value="www.stopbullyingsa.com.au/documents/bullying_employees.pdf"/>
</reference>
<reference anchor="Signs">
<front>
<title>20 Subtle Signs of Workplace Bullying</title>
<author/>
<date/>
</front>
<seriesInfo name="WEB" value="http://www.workplacebullying.org/2013/11/10/erc/ "/>
</reference>
<reference anchor="Har-Bul">
<front>
<title>Harassment and bullying at work</title>
<author/>
<date/>
</front>
<seriesInfo name="WEB"
value="http://www.cipd.co.uk/hr-resources/factsheets/harassment-bullying-at-work.aspx"
/>
</reference>
<reference anchor="Horowitz">
<front>
<title>The Effects of Team Diversity on Team Outcomes: A meta-analysis review of
team demography</title>
<author fullname="S. Horwitz" initials="S." surname="Horwitz"/>
<author fullname="I. Horwitz" initials="I." surname="Horwitz"/>
<date year="2007"/>
</front>
<seriesInfo name="Journal of Management" value="Vol 33 (6) p 987-1015"/>
</reference>
<reference anchor="Video">
<front>
<title>Workplace Bullying</title>
<author/>
<date/>
</front>
<seriesInfo name="WEB" value="http://www.youtube.com/watch?v=wAgg32weT80"/>
<annotation>(12:30min; animated; what bullying is and is not)</annotation>
</reference>
<reference anchor="Div-Discuss">
<front>
<title>IETF Diversity Discussion List</title>
<author fullname="IETF">
<organization/>
</author>
<date year="2013"/>
</front>
<seriesInfo name="WEB"
value="http://www.ietf.org/mail-archive/web/diversity/current/maillist.html"/>
</reference>
<reference anchor="Bully-Ser">
<front>
<title>Serial Bully Traits</title>
<author/>
<date/>
</front>
<seriesInfo name="WEB"
value="http://bullyonline.org/workbully/serial_introduction.htm"/>
</reference>
<reference anchor="Div-DT">
<front>
<title>Diversity Design Team wiki</title>
<author fullname="IETF">
<organization/>
</author>
<date year="2013"/>
</front>
<seriesInfo name="WEB"
value="https://wiki.tools.ietf.org/group/diversity-dt/wiki/WikiStart#"/>
</reference>
<reference anchor="Kellogg">
<front>
<title>Better Decisions Through Diversity</title>
<author fullname="Kellogg School of Management"/>
<date day="1" month="Oct" year="2010"/>
</front>
<seriesInfo name="Kellog Insight"
value="http://insight.kellogg.northwestern.edu/article/better_decisions_through_diversity"/>
<annotation>Heterogeneity can boost group performance </annotation>
</reference>
<reference anchor="WiseCrowd">
<front>
<title>The Wisdom of Crowds</title>
<author/>
<date/>
</front>
<seriesInfo name="Wikipedia"
value="http://en.wikipedia.org/wiki/The_Wisdom_of_Crowds"/>
</reference>
<reference anchor="wikiHow">
<front>
<title>How to Deal with Workplace Bullying and Harassment</title>
<author fullname="Terry" role="editor" surname="Terry"/>
<author fullname="Booky" role="editor" surname="Booky"/>
<author fullname="Versageek" role="editor" surname="Versageek"/>
<author fullname="et al" surname="et al"/>
<date/>
</front>
<seriesInfo name="wikiHow"
value="http://www.wikihow.com/Deal-with-Workplace-Bullying-and-Harassment"/>
</reference>
<reference anchor="Escalated">
<front>
<title>Workplace bullying: Escalated incivility</title>
<author fullname="Gary Namie" initials="G." surname="Namie"/>
<date month="November/December" year="2003"/>
</front>
<seriesInfo name="Ivey Business journal" value="9B03TF09"/>
</reference>
<reference anchor="Prevention">
<front>
<title>Workplace bullying - prevention and response</title>
<author fullname="WorksSafe Victoria"/>
<date month="October" year="2012"/>
</front>
<seriesInfo name="WEB"
value="www.worksafe.vic.gov.au/__data/assets/pdf_file/0008/42893/WS_Bullying_Guide_Web2.pdf"
/>
</reference>
<reference anchor="MB-Misue">
<front>
<title>Three Common Ways Libertarians Misuse Myers-Briggs Part 2:
Misunderstanding the Feeling Preference</title>
<author/>
<date/>
</front>
<seriesInfo name="WEB"
value="http://thoughtsonliberty.com/three-common-ways-libertarians-misuse-myers-briggs-part-2-misunderstanding-the-feeling-preference"
/>
</reference>
<reference anchor="Defensive">
<front>
<title>Defensive Communication</title>
<author fullname="Imelda Bickham" initials="I." surname="Bickham"/>
<date day="2013"/>
</front>
<seriesInfo name="WEB"
value="http://www.people-communicating.com/defensive-communication.html"/>
</reference>
<reference anchor="IAOC" target="https://iaoc.ietf.org/">
<front>
<title>IETF Administrative Oversight Committee (IAOC)</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="IAB" target="https://www.iab.org/">
<front>
<title>Internet Architecture Board</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="IETF" target="https://www.ietf.org/">
<front>
<title>The Internet Engineering Task Force</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="Y-H-Cybul"
target="https://support.google.com/youtube/answer/2801920?hl=en&rd=1">
<front>
<title>Harassment and cyberbullying</title>
<author fullname="Youtube"/>
<date/>
</front>
</reference>
<reference anchor="L-H-Cybul"
target="https://help.linkedin.com/app/answers/detail/a_id/34593">
<front>
<title>LinkedIn Professional Community Guidelines</title>
<author fullname="LinkedIn"/>
<date/>
</front>
</reference>
<reference anchor="F-H-Cybul" target="https://www.facebook.com/communitystandards">
<front>
<title>Community Standards</title>
<author fullname="Facebook"/>
<date/>
</front>
</reference>
</references>
<section title="Acknowledgements">
<t>This draft was prompted by the organizational change, signaled with the IESG's
adoption of an anti-harassment policy for the IETF, and a number of follow-on
activities and discussions that ensued. A few individuals have offered thoughtful
comments, during private discussions.</t>
<t>Comments on the original draft were provided by John Border and SM (Subramanian
Moonesamy).</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:04:15 |