跳到主要内容

附录 A. 动机

第 1 节概述了本文档引入的流程变更. 本附录讨论促成这些变更的背景.

A.1. 背景​

IETF 社区已经为 IETF 中的人际互动定义了一般准则 [RFC7154]. IESG 已经为 IETF 定义了反骚扰政策 [AHP], IETF 社区也定义了反骚扰程序 [RFC7776], 授权 Ombudsteam [OT] 采取必要行动.

然而, 处理 disruptive 行为并不属于 Ombudsteam 的职责. [RFC2418] 要求每个 IETF 工作组的主席调解其工作组的现场会议, 而 [RFC3934] 为主席提供了帮助管理邮件列表的程序. 一份 IESG 声明 [MODML] 向工作组主席提供了关于如何调解其列表的补充指导, 但并未说明何时进行调解.

对于不隶属于工作组的 IETF 邮件列表, 另一份 IESG 声明 [DP] 澄清, IESG 将调解职责交给列表管理员. 此外, 主要由于历史原因, 用于一般讨论的 IETF 列表有一个 moderator 团队, 这些 moderator 不是列表管理员, 并且按照另一套流程运作 [RFC9245].

注意, "moderation" 一词既可以指 preemptive moderation, 即管理员在参与发生前审查拟进行的参与 (例如审查发送到邮件列表的消息), 也可以指 reactive moderation, 即管理员在 disruptive participation 已经发生后进行干预. 从历史上看, IETF 主要采用 reactive moderation, 所采取的措施从列表内外的温和提醒, 一直到暂停发帖权以及其他参与或沟通方式. moderator 和 administrator 可以作为其程序的一部分, 决定采用何种 preemptive 与 reactive moderation 组合.

此外, [RFC3683] 定义了一项流程, 用于在社区对 IESG 提议的 "posting rights" action (PR-action) 进行 Last Call 之后撤销个人向 IETF 邮件列表发帖的权利; 此类 action 通常是对社区投诉的回应.

经验和社区反馈表明, 有必要演进现有流程.

A.2. 先前方法存在的问题​

先前通过主席, 列表管理员和 moderator 团队调解 disruptive participation 的方法, 再加上由 IESG 主导的 PR-action 流程, 已被证明并不理想:

  • IETF 社区一直无法就 disruptive behavior 的通用定义达成一致. 因此, 主席和列表管理员在作出决定时会分别适用不同标准, 而参与者对于何时应采取 PR-action 也有不同预期.

  • 主席和列表管理员需要遵循的 moderation 流程 [RFC3934] 缓慢且繁琐, 因而不适合迅速升级的情形. 它还假定 disruptive behavior 的发起者是可以讲道理的误入歧途的参与者, 并且会改变其行为方式.

  • 主席和列表管理员只能对其单个列表采取 moderation action, 当 disruptive behavior 的模式跨越多个列表时, 这并不适合. 此外, 由于未订阅其中某些列表, 主席和列表管理员可能无法完全知悉跨多个列表发生的 disruptive behavior.

  • PR-action 虽然可以处理跨多个列表的 disruptive behavior, 但流程繁琐, 缓慢且不一致. 这导致 PR-action 很少被使用; 而一旦使用, 又会被认为手段过重.

  • 对于给定邮件列表, 参与者可能出于各种原因而不愿向主席或列表管理员报告 disruptive behavior. 对于不隶属于工作组的邮件列表, 列表管理员甚至不会被公开标识, 只能通过匿名别名地址联系. 这会加剧问题, 因为参与者可能不愿向匿名方报告 disruptive behavior.

  • moderation 流程只针对 IETF 中的两类参与渠道定义: 现场会议和邮件列表. 然而, IETF 事务现在发生在许多论坛中 (例如, 聊天组, 远程会议参与系统, 虚拟会议, wiki 和 GitHub 仓库). 目前尚未定义在这些论坛中调解 disruptive behavior 的程序.

最后于 更新