Re: [FFmpeg-devel] The Concept for the CC Installment is broken by Design

[Soft Works <softworkz-at-hotmail.com@ffmpeg.org>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Soft
> Works
> Sent: Freitag, 7. März 2025 05:36
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: [FFmpeg-devel] The Concept for the CC Installment is broken by
> Design 

[..]

> The Community Committee Concept is broken by Design
> ===================================================


To be honest - I've been a bit shocked that my message could have been misunderstood so badly, but I hope it has become clear enough how I mean it.

As it is my belief that one should not criticize without offering any suggestions, I want to share my ideas on the subject. I don't have a full-blown concept in all detail, but a number of core elements that could serve as building blocks for a re-design of the current structures.


1. Clear separation of activities

I see two major areas of activity with regards to - let's say - "Community Management"

  - Resolution of Interpersonal Conflicts between Members
  - Moderation of Public Communications
     like on the ML or in a future Git Portal environment

Whether the same persons should be in charge for both of these - I don't think that. It's important to avoid any collisions of interest and put everything on more and different shoulders, with a clear definition of the kind of actions that each activity involves and which not.


2. Resolution of Interpersonal Conflicts between Members

The GA elects 3 "Persons of Trust" => PoTs

The PoTs are working only loosely together.

There are no formal measures (like a "warning") issued, neither publicly nor privately.

All activity remains always and forever private.

When a member is facing an interpersonal issue s/he can contact a PoT of her/his choice.
They discuss the problem and talk about how to proceed, individually, on a case-by-case basis.
The PoT may suggest to involve other PoTs (e.g. like when another PoT has a better relationship with the target person).
The member may agree or may not agree. In the latter case, the contacted PoT will not share any information about the case with the other PoTs.

It may sound somewhat similar at first glance - but it's fundamentally different and eliminates pretty much all of the bad effects that I've laid out in the previous message.


3. Moderation of Public Communications


Core Points:

- Moderation team members should not be well-known persons => people from the GA do not qualify
- Moderation activity is not driven by hints or complaints
- Moderators are working proactively, i.e. they have to read everything and are not acting 
  on request from others; they must ignore any such requests
- Moderators can issue warnings of different severity levels
  A warning includes:
  - An amount of warning points
  - A number of hours for which the member is blocked from posting/sending.
  - Warning points are publicly visible
- Actions of moderators cannot be questioned or disputed
- Moderation activity is public and transparent
  except:
- The moderators are working and appearing as a team and this is where
  transparency ends: it will never become public which member of the team
  has taken a specific action

Thoughts and Ideas

The above is loosely based on the way things are done in our forums. These are moderated very well by volunteers (plus one admin who oversees them). No matter which time of day, I've never seen a spam post surviving more than 10 minutes. The way how warnings are issued is consistent - i.e. not different depending on which of the mods did it. 
From that I know that it's normally feasible do it that way. But I'm not sure whether it could work here as well, without causing more dystonia in the community again.

Sentiment analysis has almost become a standard measure for protecting communication these days. That made me wonder whether it might not be a better solution (or one component of a concept) for ML moderation. The problem is that such moderation is rather pointless when it's not done right in the moment when a conversation goes off rails. Blocking members from posting is in such situations is the best and most proven way to avoid escalations. In almost all cases, participants of such conversations will write a different kind of text on the next day than they would have in that moment. That's why instant moderation is an inevitable element IMO.

Those suggestions are not arbitrary. I really don't know why I've spent so much thought on this subject, but almost all the details I mentioned have a specific intention and a match in the range of problems I had described before.


I hope it makes sense to somebody, thanks for reading
sw
















_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".