Last Call: <draft-farrresnickel-harassment-08.txt> (IETF Anti-Harassment Procedures) to Best Current Practice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This document has been in last call previously, and one issue in particular
caused concern. A design team was  created in May 2015 to address this
issue, and the document has also otherwise been updated. See further
below for a detailed list of changes and history.

The sponsoring Area Director believes a new formal last call is needed
to ensure that the resulting document matches the community's
expectations on this important topic.

The sponsoring Area Director also believes that this is a topic where
it is important to have an official IETF policy. Policies relating to
human behaviour can be difficult topics to deal with, particularly
in the all-cases-fully-specified manner that we are accustomed in
our technical work. However, policies can be also be updated
if later experience proves they have issues.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-09-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

- 'IETF Anti-Harassment Procedures'
  <draft-farrresnickel-harassment-08.txt> as Best Current Practice

The file can be obtained via
https://datatracker.ietf.org/doc/draft-farrresnickel-harassment/

Changes since the previous last call can be seen via
https://tools.ietf.org/rfcdiff?url1=draft-farrresnickel-harassment-05.txt&url2=draft-farrresnickel-harassment-08.txt

Adrian Farrel, one of the document editors stated this as a summary
of the changes on the IETF list (the email is copied below and originally
from http://www.ietf.org/mail-archive/web/ietf/current/msg94129.html):

----

After some very fruitful mail exchanges on and off the list and some detailed
discussions face-to-face in Prague, we have produced a new revision of the 
anti-harassment process document.

Some of the changes are quite large. Others are small, but subtle. I 
recommend reading the whole document, but if you want to look only
at changes, I suggest you diff against -05, the version that was updated
after IETF last call and went to the IESG for evaluation

In checking to see what changes were made and whether they addressed 
your comments, please bear in mind that there were a lot of comments 
made in a conversational manner and it was quite hard to round them 
up and determine exactly what changes needed to be made. Ines did a 
great job helping as Shepherd, but if we have missed something you 
said, it is not because we are ignoring you: it's just that we lost the 
point amongst other comments and discussions.

Additionally, I'd ask you to think about whether what we have is "good 
enough" to act as a starting point. I'm conscious that we have been 
debating having this piece of process for a long time and that my 
personal preference is to get something going (a beta release?) and 
then tune it as we go forwards. In the light of that I know that 
consensus on some parts of the document may be a little rough. 
This mainly happens when the opinions on an issue are very 
divergent and not easily brought together. I hope that we have 
done a good job at building bridges, but will not be surprised 
or upset if some of you are not happy.

I'm responsible for most of the edits in this round (with 
assistance from multiple people) so please blame me 
(and complain about me to Pete) for any nonsense.

As to process, I suggest that this document needs to be
taken around for another IETF last call, but I leave that
to Jari as the responsible AD.

Thanks,
Adrian

------

In summary...

Abstract: clarify the nature of updates to existing RFCs.

Introduction: s/interpersonal/personal/

Definitions: Clarify that the definition of harassment is deliberately not
a closed list.

Definitions: Add a paragraph (loosely based on the IEEE's equivalent
policy) to scope when harassment applies within the IETF.

Definitions: Add a clause recommended by our lawyers about applicable law.

Ombudsteam: Clarify "recompense" to mean "compensation from the IETF".

Term of Service: Add paragraph for when an Ombudsperson's term ends 
while they are acting as Lead Ombudsperson .

Term of Service: Add a note about likelihood of reappointment.

Compensation: Clarify "recompense" to mean "compensation from the IETF".

Removal: Expand the times that an Ombudsperson can be removed.

Handling Reports: Fix email address and URL.

Handling Reports: Clarify that remedies are imposed only after 
completing investigations.

Operating Practices: Expand on confidentiality expectations.

Operating Practices: Clarify that the Respondent is contacted and 
given an opportunity to interact before a remedy is imposed.

Operating Practices: Add when the Ombudsteam must commit things to writing.

Remedies: Add that mediation ned not be an end point.

Remedies: Show how remedies may be actioned through the Secretariat or IAD.

Remedies for Respondents in IETF Positions: Add substantial new section.

Purpose of Remedies: Expand on the details and theme of "not as 
punishment" remedies.

Confidentiality: Add new section to describe expectations.

Acknowledgements: What a lot of you have helped with this document!




[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux