Re: [Gendispatch] New Version Notification for draft-ecahc-moderation-00.txt

Hi folks,

I think this is a good idea and this draft is a good start. I have
made a few comments below, but I want to make one general suggestion
for enhancement.

In my experience one of the things that makes moderation difficult
is when each moderation decision is itself subject to extensive
debate in the same venue as it is happening. This constitutes a
DoS on the venue as well as discouraging strong moderation. I
think it would be good to establish a separate venue for debating
moderation discussions (e.g., an issue tracker or something)
that is distinct from the lists being moderated. This will allow
for public debate where necessary but not subject everyone else to it.

S 4.1.
   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.

So these do not require approval of IAB or IESG?

   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.

I think you should clarify that this is confidential.

Maybe I'm missing it, but it's not clear to me what the *powers*
of moderators are. For instance, can they ban someoen entirely
from a list? From an IETF list? It just seems to say "moderation
actions". FWIW my view is they should have quite broad powers.

S 4.2.

   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.

I think this should probably be a MUST and I would change it to
forbid someone becoming a moderator and then joining the I*.

   Because the IESG and IAB are in the appeals chain for moderator team
   decisions (see Section 4.3), serving members of the IESG and IAB
   MUST NOT serve as moderators.

I don't see a clause that allows replacing moderators. That seems
like it needs to exist.

S 4.4.
   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.

This seems to implicitly assume a very high level of responsiveness
(24x7). I'm not sure that's necessary but if you think it is, then
you should say so.

-Ekr

On Thu, Jul 6, 2023 at 12:33 PM Salz, Rich <rsalz=
40akamai.com@dmarc.ietf.org> wrote:

> I am posting to the gendispatch list because that is where the document
> says discussion should happen.
>
>
>
> In Section 3, Motivation, the MODML reference doesn’t really give guidance
> to chairs for this general case being discussed by this document. It
> describes how WG chairs should act if they make their WG list moderated,
> which is different.
>
>
>
> The term PR-Action should be defined when first used, I think.
>
>
>
> In section 4.1, Scope, the sentence “If is not expected that the moderator
> team will be monitoring every IETF channel…” should appear much earlier in
> the document.
>
>
>
> In Section 4.3, Appeals, this sentence confuses me: Disagreements with a
> decision by the IETF Chair can be brought to their attention.  Does “their”
> refer to the IETF Chair? And if so, is it reasonable to expect that the
> IETF Chair having decided will change their mind? Isn’t disagreements with
> IETF Chair decisions can be appealed?
>
>
>
> Have you considered having some subset of the organizational bodies and
> ISOC appoint members or liaisons?
>
>
>
> *From: *Lars Eggert <lars@eggert.org>
> *Date: *Thursday, July 6, 2023 at 1:48 PM
> *To: *'WG Chairs' <wgchairs@ietf.org>
> *Cc: *Alissa Cooper <alcoop@cisco.com>, Brian Carpenter <
> brian.e.carpenter@gmail.com>, Jari Arkko <jari.arkko@ericsson.com>
> *Subject: *Fwd: New Version Notification for draft-ecahc-moderation-00.txt
>
>
>
> Hi,
>
>
>
> FYI, we've just submitted a proposal for a new approach to moderating the
> IETF's various contribution channels. It borrows a lot from the current
> moderation approach for the IETF discussion list, but applies the idea to
> all the IETF's contribution channels.
>
>
>
> One open question is if WG chairs should retain the task (or at least
> ability) to moderator their WG lists. We'd be interested in your thoughts
> here, and of course on anything else related to the document.
>
>
>
> Please do note that it's a -00 and has some known omissions, but we wanted
> to float the idea at this time so we can discuss at IETF 117.
>
>
>
> Thanks,
>
> Lars
>
>
>
> PS: Note that I will be on vacation until July 17, but (most) of the
> co-authors should be around.
>
>
>
> Begin forwarded message:
>
>
>
> *From: *internet-drafts@ietf.org
>
> *Subject: New Version Notification for draft-ecahc-moderation-00.txt*
>
> *Date: *July 6, 2023 at 20:41:29 GMT+3
>
> *To: *"Brian E. Carpenter" <brian.e.carpenter@gmail.com>, "Alissa Cooper"
> <alcoop@cisco.com>, "Brian Carpenter" <brian.e.carpenter@gmail.com>,
> "Jari Arkko" <jari.arkko@ericsson.com>, "Lars Eggert" <lars@eggert.org>,
> "Russ Housley" <housley@vigilsec.com>
>
>
>
>
> A new version of I-D, draft-ecahc-moderation-00.txt
> has been successfully submitted by Lars Eggert and posted to the
> IETF repository.
>
> Name:                   draft-ecahc-moderation
> Revision:              00
> Title:                      IETF Community Moderation
> Document date:                2023-07-06
> Group:                  Individual Submission
> Pages:                   9
> URL:
> https://www.ietf.org/archive/id/draft-ecahc-moderation-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-ecahc-moderation/
> Html:
> https://www.ietf.org/archive/id/draft-ecahc-moderation-00.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ecahc-moderation
>
>
> Abstract:
>   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.
>
>
>
>
> The IETF Secretariat
>
>
> --
> Gendispatch mailing list
> Gendispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/gendispatch
>