Appendix A. Motivation

Dieser Abschnitt bewahrt den RFC-Text zur IETF community moderation, einschliesslich disruptive participation, moderator team, procedures, transparency, appeals, reinstatement sowie der Beziehungen zu Ombudsteam und IETF LLC.

Originaler RFC-Text

Appendix A.  Motivation

   Section 1 summarizes the process changes introduced by this memo.
   This appendix discusses the background that led to them.

A.1.  Background

   The IETF community has defined general guidelines for personal
   interactions in the IETF [RFC7154].  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.  [RFC2418] tasks the chairs of each IETF working
   group with moderating their group's in-person meetings while
   [RFC3934] provides chairs a procedure to help manage mailing lists.
   An IESG statement [MODML] describes additional guidance to working
   group chairs about how -- but not when -- to moderate their lists.

   For IETF mailing lists not associated with a working group, another
   IESG statement [DP] clarifies that the IESG tasks list administrators
   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].

   Note that the term "moderation" can refer both to _preemptive_
   moderation, where administrators review attempted participation
   before it occurs (such as reviewing messages to a mailing list), and
   _reactive_ moderation, where administrators intervene after
   disruptive participation has occurred.  Historically, the IETF has
   mainly practiced reactive moderation, employing actions ranging from
   gentle reminders on- and off-list, all the way to suspension of
   posting rights and other ways of participating or communicating.  It
   is up to the moderators and administrators to decide which mix of
   preemptive and reactive moderation to employ as part of their
   procedures.

   In addition, [RFC3683] defines a process for revoking an individual's
   posting rights to IETF mailing lists following a community Last Call
   of a "posting rights" action (PR-action) proposed by the IESG, often
   in response to complaints from the community.

   Experience and community input suggests that an evolution of the
   existing processes is necessary.

A.2.  Problems with the Previous Approach

   The previous 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:

   *  The IETF community has not been able to agree on a common
      definition of disruptive behavior.  Therefore, chairs and list
      administrators apply individually different criteria when making
      decisions, and participants have different expectations for when
      PR-actions are warranted.

   *  The moderation process that chairs and list administrators need to
      follow [RFC3934] is slow and cumbersome, which makes it ill-suited
      to situations that escalate quickly.  It also assumes that the
      originator of disruptive behavior is a misguided participant who
      can be reasoned with and who will change their ways.

   *  Chairs and list administrators may only enact moderation actions
      for their single list, which is ill-suited when a pattern of
      disruptive behavior spans multiple lists.  Also, chairs and list
      administrators may not be fully aware of disruptive behavior that
      spans multiple lists, due to not being subscribed to some of them.

   *  PR-actions, which can address disruptive behavior across several
      lists, are cumbersome, slow, and inconsistent.  This has led to a
      situation where PR-actions are rarely used, and when they are
      used, they are perceived as very heavy-handed.

   *  For a given mailing list, participants may not feel comfortable
      reporting disruptive behavior to a chair or list administrator,
      for various reasons.  For mailing lists not associated with
      working groups, list administrators are not even publicly
      identified -- they can only be contacted through an anonymous
      alias address.  This exacerbates the problem, because participants
      may not be comfortable reporting disruptive behavior to an
      anonymous party.

   *  Moderation processes have been defined for only two channels of
      participation in the IETF: in-person meetings and mailing lists.
      However, IETF business now happens in a number of fora (e.g., chat
      groups, remote meeting participation systems, virtual meetings,
      wikis, and GitHub repositories).  Procedures for moderating
      disruptive behavior in these fora are currently undefined.