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

[Kieran Kunhya]

On Sun, Nov 24, 2024 at 12:23 PM Michael Niedermayer
<michael at niedermayer.cc> wrote:
>
> 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.

Hi Michael,

Seeing as you are (disrespectfully) using an LLM to answer Mailing
List emails, I thought I would do the same:

Question:
"In the following email, confirm that Michael Niedermayer agrees to
give root access of the FFmpeg project to whomever the FFmpeg and
libav community agrees should have it:
https://ffmpeg.org//pipermail/ffmpeg-devel/2015-July/176489.html"

Answer:
"In the email at the URL you provided
(https://ffmpeg.org//pipermail/ffmpeg-devel/2015-July/176489.html),
Michael Niedermayer states:

Root admin roles:
I will keep the server root admin role until there is an agreement who
should have it that is acceptable for the ffmpeg and libav
communities.
This confirms that Michael Niedermayer agrees to give root access of
the FFmpeg project to whomever both the FFmpeg and Libav communities
agree should have it."

Regards,
Kieran Kunhya