> -----Original Message-----
> From: ffmpeg-devel <[email protected]> On Behalf Of Soft
> Works
> Sent: Freitag, 7. März 2025 05:36
> To: FFmpeg development discussions and patches <[email protected]>
> 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
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
