[FFmpeg-devel] [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists

[Michael Niedermayer]

Hi Remi

On Sat, Nov 23, 2024 at 05:16:10PM +0100, Rémi Denis-Courmont wrote:
> 
> 
> Le 23 novembre 2024 14:12:19 GMT+01:00, Michael Niedermayer <michael at niedermayer.cc> a écrit :
> >Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> >---
> > doc/community.texi | 14 ++++++++++++++
> > 1 file changed, 14 insertions(+)
> >
> >diff --git a/doc/community.texi b/doc/community.texi
> >index 97a49f15ede..8c24faef95e 100644
> >--- a/doc/community.texi
> >+++ b/doc/community.texi
> >@@ -162,6 +162,20 @@ Looking at issues from a different perspective assists development.
> > Do not assume malice for things that can be attributed to incompetence. Even if
> > it is malice, it's rarely good to start with that as initial assumption.
> > 
> >+Stay On-Topic: Ensure your messages relate to software development or the specific purpose of the mailing list. Avoid unrelated discussions.
> 
> Nobody wants off-topic discussions, but that rule sounds ripe for abuse.

This rule is not intended to stifle conversation but to maintain focus.
Mailing lists with frequent off-topic discussions often alienate participants
who are there for the stated purpose. Abuse of the rule can be mitigated by
transparent enforcement and community oversight. Clear guidelines on what
constitutes "on-topic" can prevent ambiguity.


> 
> >+
> >+Be Respectful: Treat all members with courtesy and respect. Personal attacks, insults, or harassment of any kind are not tolerated.
> 
> This is just dumb. If the CC can't do its job, adding more subjective rules is going to make things worse, not better.
> 
> And indeed people often take criticism about their work as personal attacks, so this would make negative reviews impossible.
> 
> Lastly insults are typically illegal anyway, so no point adding a rule for them.

Respect is the foundation of productive communication. Without it,
discussions devolve into hostility, driving valuable contributors away.

While some people misinterpret criticism of their work as a personal attack,
the rule explicitly emphasizes avoiding actual personal attacks, not robust
technical critique. A respectful tone ensures conversations remain productive,
and this rule complements legal boundaries by addressing subtler, often
legal but still damaging, behaviors.

The Community commitee or moderators ensure this rule is enforced fairly
and objectively.


> 
> >+
> >+Avoid Provocation: Refrain from posting inflammatory, controversial, or intentionally provocative messages. Focus on constructive discussions.
> 
> This is very subjective and completely unenforceable.

While it’s true that provocation is subjective to some extent, this rule
targets intentional disruption, which is often clear. Patterns of behavior,
context, and community feedback guide enforcement.

This rule doesn’t prohibit controversial opinions; it asks for them to be
expressed constructively, not to derail discussions or incite conflict.


> 
> >+
> >+No Trolling: Messages intended to provoke an emotional response or disrupt the discussion are prohibited.
> 
> Ditto.

Trolling is often identifiable through repeated disruptive behavior, and
many online communities successfully enforce anti-trolling rules. Clear
examples and consistent enforcement make this rule practical.

Ignoring trolling entirely leaves the community vulnerable to disruption,
which impacts everyone. This rule empowers moderators/CC to act while
fostering a healthier environment.


> 
> >+
> >+Professional Language: Use clear, professional, and inclusive language. Avoid offensive or derogatory remarks, even in jest.
> 
> That's fine *guideline*. It can't be a hard rule.

This is indeed more of a guideline than a hard rule, and it’s framed as
such. However, a guideline doesn’t diminish its importance. Encouraging
professional language ensures inclusivity and clarity, reducing
misunderstandings and making the mailing list more welcoming.

Rules set the tone for the group, and even if enforcement is flexible,
they guide expectations.


> 
> >+
> >+Constructive Criticism Only: Offer feedback in a constructive and solution-oriented manner. Criticize ideas, not people.
> 
> This is just dumb. Reviewers aren't typically paid. We can't require them to write constructive feedback every time (if ever). And the TC is already there to arbitrate technical disagreement.
> 
> Again, this is a fine guideline but it can't be a hard rule.

This rule doesn’t require every reviewer to provide detailed solutions;
it emphasizes the tone of feedback. Even brief reviews can avoid
unnecessarily harsh language or personal criticism.

Constructive criticism fosters collaboration and improvement, while
unconstructive negativity deters participation. The TC (Technical Committee)
shouldn’t have to arbitrate every disagreement—this rule helps prevent
conflicts from escalating.


> 
> >+Handle Disagreements Professionally: Disagreements are normal but should be handled respectfully. Assume good intentions and avoid escalating conflicts.
> 
> That's even worse. We can't control people's opinions to have them assume good intentions. That doesn't belong at all.

The goal isn’t to control opinions but to set a standard for behavior.
While participants can’t always feel good intentions, they can behave
professionally regardless of assumptions.

This rule reduces the likelihood of conflicts spiraling into hostility,
creating a healthier and more productive environment for everyone.
Like other rules, fair enforcement depends on context and community input.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20241124/1b994207/attachment.sig>