Minutes IETF121: modpod
minutes-121-modpod-00

MODPOD - Moderation Procedures
IETF 121, Dublin, IE

Thanks to Richard Barnes for raw notes; Lisa Dusseault summarized.

1. Chairs intro

* Introduced what the WG has for input documents
* Discussion of goals, especially to address how PR actions are a heavy-weight
process * Should moderation procedures be lighter-weight, more discreet? *
Roman Daniliw's editorial comment: This is extremely critical for IETF.

⠀
2.  Document update (Eliot Lear)

The Charter already clarifies some consensus on approaches, e.g.allowing more
consistent moderation across venues.

The authors of two of the drafts (-ecahc-moderation and -bcp83-replacement) are
talking about merging best parts of each. There are differences between those
two drafts, but both drafts say that the mod team has wide latitude.  Both the
draft by Lear and the draft by Sayre provide graduated response and graduated
transparency to reduce the "all or none".  Proposed plan:

3. Discussion

There was definite support for much of the direction of the two drafts, and for
combining them. Some additional points: * A process concern about combining
both docs is that if the goal is to replace BCP83, which is focused on banning
from mailing lists, this is a narrower scope than the WG's overall scope, and
perhaps there should be separate docs for replacing BCP83 vs other work. 
Others thought that one document could still achieve replacing BCP83 as well as
the larger scope.

* Question about  how the Ombudsteam fits into this?  Roman noted that updating
RFC 7776 (Ombuds procedures) is out of scope

* Point made that specifying overly-precise procedures is usually wrong. 
Ideally, make a short document defining areas of responsibility., then the
persons responsible should publish their working methods.  Overly-precise rules
lead to nitpicking as well, and discretion is important.

* General agreement about some useful tools of moderation: it helps to have
several actions or options to choose ; warnings are often useful to moderate
behavior even without any firm action; quicker moderation is better.

* Several contributors were concerned about moderation being used  to control
participants by chairs/mod-teams with a bias or agenda.

* Roman also noted that updating RFC 7154 is out of scope

* Some discussion of the desired future scope of a moderation team included
tradeoffs in different directions - trusting WG chair discretion vs lightening
the load of chairs, the ability of a moderation team to scale to many lists,
etc. Note stats from existing moderation team:
(https://github.com/ietf/Moderators/blob/main/stats.md)

* Some discussion of whether moderation could be an LLC function, but clearly
many folks saw value in moderation as a community function.  A possible
combination model would be to set policies or make difficult decisions via
community representatives, but delegate more routine work to the LLC

* Discussion of whether this could be run quickly as a process experiment? 
Since there's widespread desire to replace BCP83 an experiment wouldn't replace
that; also a document would still be required to run an experiment.  In any
case, doc work comes first.

4. Consensus call

* Jon: Does anyone object to us using these 3 docs as a starting point?
  * 35 Yes, 1 No, 4 No opinion

Call for consensus: Consolidate using ecahc as a baseline
* 22 yes, 1 no, 14 no opinion

Conclusion: either of these seems like an approach the authors can take with
support from participants.