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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
