[FFmpeg-devel] [ANNOUNCE] upcoming vote: CC election
Marth64
marth64 at proxyid.net
Thu Dec 19 05:40:51 EET 2024
Hi Michael,
> can you maybe provide a few more details so I and people know better
> how you would handle concrete examples, here are some:
Yes, sure.
Let us start with the booths.
Unpacking this one based on information provided above and what I
found in archives,
Statement #1 (NAB 2023)
----
* Trademarked FFmpeg branding was used by a different organization
without clear authorization.
* There was no visible process with the FFmpeg community (GA)
approving the IP use.
* Two or more contributors were present at the booth, resulting in a
mixed image of brand ownership.
Statement #2 (NAB 2024)
----
* Booth announced in Nov 2023 with "anonymous corporate sponsorship"
and vague expense process.
* There was a brief, heated exchange on the ML about the source of
funding, but the booth was opened anyway.
* FFmpeg contributors who passed by the booth questioned its
legitimacy due to seeing nobody.
* Ultimately the booth was revealed to be staffed but the thread
exploded due to the initial disagreement.
There are two problems in both situations.
*** Problem 1 ***
First of all, there is a logistics issue. There needs to be a
conference/booth registry of sorts
with a crystal clear approval workflow. This project appears to have
outgrown the casualty
of simply email dropping "a booth will occur" and likewise deserves
better than to have
an unauthorized/unsocialized booth occurs. We need a registry process.
Practically I am talking about a simple registration process here.
This can literally be a word processing document or spreadsheet. I
don't really care.
We do not need to go write code or build bespoke solutions for this.
But it needs to be a more material artifact than an email chain. It is
two steps:
(1) Initiate request with a documented form:
- Owner of this registration request?
- Date/time of booth?
- Location?
- Justification?
- Source of booth expenses?
- Source of travel expenses?
- Who from the community will staff the booth?
- ...
(2) Get approvals from whoever the GA delegates to approve booths
We can and need to figure out who can give this authoritative
signature, AKA "approvers".
This can be a majority GA vote, CC+TC combined, trademark owner, fund
managers, or all of the above.
And if these options don't find a majority liking then we need an RFC
to decide who.
Ideally it would be a frictionless process and not have too many hands
on the pot.
I would expect these approvers to apply prudent judgement when
evaluating the requests.
Then they sign the form with a yes/no.
People can still steal the IP and go use it in an unauthorized way.
But now, we can at least build an authoritative written data record of
what IS authorized.
By drying this out to a form and elected group of approvers, we lift
the emotion out of it,
and we have formal documentation.
More importantly, we also build a process rather than melt down in
emails. Which leads me to...
*** Problem 2 ***
The second issue is professionalism. Yes, this is an open source
community. Speak free and have fun.
But I imagine we are all adults and should apply constructive candor
to our responses.
If we look back at the aforementioned two NAB 2024 ML threads, it is
obvious they fell apart quickly.
Some of the responses there have zero business value and are
inappropriate to share on a public ML.
There could have been more proactive moderation in these emails.
For the trolling/inappropriate responses,
CC should have and in one instance did respond. But CC consequential
responses should be consistent
and could have been applied more broadly. There should be zero
tolerance for these types of responses.
Adverse action needs to be declared or people will keep doing it. Examples:
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325781.html
(redirection/joke)
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325795.html
(hungover comment)
I have nothing against the engineers who wrote this.
But what value did these add really?
CC should have been empowered to step up and say, "we've got a toxic
discussion here,"
and really email is a painful way to resolve it. There could have been
virtual IRC meetings
or even phone calls to hash out the root issue. Instead it was left to
drag on and on.
This is fine for code reviews. This is BAD for building positively
thinking communities.
I will write in a following email about the banning/bias (most recent case)
shortly, after I read the threads again.
More information about the ffmpeg-devel
mailing list