| Internet-Draft | IETF Community Moderation | July 2023 |
| Eggert, et al. | Expires 7 January 2024 | [Page] |
This document describes the creation of a moderator team for all of the IETF's various contribution channels. Without removing existing responsibilities for working group management, this team enables a uniform approach to moderation of disruptive participation across all mailing lists and other methods of IETF collaboration.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://larseggert.github.io/moderation/draft-ecahc-moderation.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ecahc-moderation/.¶
Discussion of this document takes place on the gendispatch Working Group mailing list (mailto:gendispatch@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/gendispatch/. Subscribe at https://www.ietf.org/mailman/listinfo/gendispatch/.¶
Source for this draft and an issue tracker can be found at https://github.com/larseggert/moderation.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 7 January 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document proposes the creation of a moderator team for all of the IETF's various contribution channels. This moderator team is modeled after, and subsumes, the moderator team for the IETF discussion list [RFC9245].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The IETF community has defined general guidelines of conduct for personal interaction in the IETF [RFC7154], and the IESG has defined an anti-harassment policy for the IETF [AHP] for which the IETF community has defined anti-harassment procedures [RFC7776], empowering an ombudsteam [OT] to take necessary action.¶
Dealing with disruptive behavior, however, is not part of the role of the ombudsteam. [RFC3934] task the chairs of each IETF working group with moderating their group's in-person meetings and mailing lists, and an IESG statement [MODML] describes additional guidance to working group chairs. For IETF mailing lists not associated with a working group, another IESG statement clarifies [DP] that the list administrators are tasked with moderation. And the IETF list for general discussions has, mostly for historic reasons, a team of moderators that are not list administrators and operate by a different set of processes [RFC9245].¶
In addition, [RFC3683] defines a process for revoking an individual's posting rights to IETF mailing lists following a community last-call of a "PR-action" proposed by the IESG, often in response to complaints from the community.¶
This fractured approach to moderation of disruptive participation through chairs, list administrators, and moderator teams, combined with the IESG-led process of PR-actions, has proven to be less than ideal:¶
This document proposes a different, uniform approach to moderating the IETF's various participation channels: a moderator team for the IETF. The creation of this team intends to address the issues identified in Section 3.¶
This IETF moderator team consists of a small number of individuals (no less than three) that SHALL moderate all the IETF's various current and future participation channels. At present, these include mailing lists, chat channels, and discussions in other systems that the IETF or WGs have chosen to employ, such as GitHub repositories, Wikis, or issue trackers.¶
The management and moderation of in-person, remote, and interim meetings remains a task of the relevant group's management, such as WG chairs. However, it is expected that moderators are available for consultation and assistance should issues arise, and they may confer with the group management over potential patterns of behavior.¶
The moderator team SHALL operate according to a consistent and uniform set of criteria, processes, and actions. The moderator team SHALL independently define and execute their role. They SHALL maintain a public set of moderation criteria, processes, actions, and other material that allows the community to understand and comment on the role of the team. The moderator team SHOULD consider adopting moderation criteria, processes, and actions that other technical communities have found suitable. The moderator team's criteria and processes SHALL be developed with community input, but they are not expected to be documented in the RFC series.¶
The moderator team MAY initiate moderation actions by itself; individual participants SHOULD also alert the team to disruptive behavior they observe. Participants should be able to contact the moderator team in ways that are, ideally, integrated into the various participation channels the IETF offers.¶
It is not expected that the moderator team will be monitoring every IETF channel, but rather that participants will proactively flag concerns about disruptive behavior to the moderator team. However, the moderator team SHOULD actively monitor a small set of key participation channels, including, for example, the IETF discussion and last-call mailing lists or the IETF plenary chat channel. The moderator team should decide which channels are in this set based on their own judgement and community suggestions.¶
The IETF Chair appoints members of the moderator team. Apart from appointing moderators, the IETF Chair SHALL refrain from the day-to-day operation and management of the moderator team. The moderator team MAY decide to consult with IETF Chair when needed.¶
Because the IESG and IAB are in the appeals chain for moderator team decisions (see Section 4.3), the IETF Chair SHOULD NOT appoint a moderator who is serving on the IESG or IAB. Individuals serving on other bodies to which the NomCom appoints members, such as the IETF Trust or the LLC Board, as well as LLC staff and contractors SHALL also be excluded from serving on the moderator team. If a moderator is assuming any such role, they SHALL step down from the moderator team soon after.¶
Because the moderator team serves at the discretion of the IETF Chair, any moderation decision can be appealed to the IETF Chair, per [RFC2026]. Disagreements with a decision by the IETF Chair can be brought to their attention. If this does not lead to a resolution, the decision can be appealed as described in [RFC2026], as with any other Area Director decision. In this case, the appeals chain starts with an appeal to the entire IESG.¶
Due to the global nature of the IETF, the membership of this team SHOULD reflect a diversity of time zones and other participant characteristics that lets it operate effectively around the clock and throughout the year. Team diversity is also important to ensure any participant observing problematic behavior can identify a moderator they feel comfortable contacting.¶
The moderator team SHALL complement the efforts of the IETF ombudsteam [OT], whose focus on anti-harassment and operation SHALL remain unchanged. The moderator team and ombudsteam are expected to work together in cases that may involve both disruptive behavior and harassment; they may determine the most effective way to do so in each case.¶
The ombudsteam has strict rules of confidentiality. If a moderation case overlaps with an ombudsteam case, confidential information MUST NOT be shared between the teams.¶
Creation of the IETF moderator team requires some changes to existing RFCs and also requires the IESG to update a number of their statements. This section describes these changes.¶
The usual security considerations [RFC3552] do not apply to this document.¶
Potential abuse of the moderation process for the suppression of undesired opinions is counteracted by the availability of an appeals process, per Section 4.3.¶
This document has no IANA actions.¶
These individuals suggested improvements to this document:¶