There are lots of developers that consume FFMPEG and have a vested interest in its development continuing smoothly... I count myself among them. I dont think it would be hard to impanel a group (3-4) of reasonable and dispassionate people to officiate and moderate public communication.
As an observer it seems like some of the disagreements fall into a few categories. 1) Constructive criticism done in a way that could be interpreted as threatening or dismissive. 2) Legitimate disagreements about implementation (reuse side_data or add a field to a struct; etc). 3) Language that might be completely acceptable in another language or in verbal communication, but "Comes off wrong" in the context of a code review. 4) The least common is someone actually being intentionally malicious... this is much, much less common than it used to be. Then there are complicating personality factors: Some people take criticism poorly, and take personal offense when no ill will is intended. Core developers have been working together for a long time, and often times there is some stored up ill will. with a spelled out code of conduct you get rules and transgressions of rules, and reprimands and ultimatums, etc... but the incentives don't work well with volunteers. It seems like it would be more effective to have a body that can just communicate a community standard out of band of this list. If a CoC needs to be in place in order to banish someone to a new email address... or to have process to strip committing privileges, so be it. -- grady (uninformed spectator) > On May 17, 2018, at 10:09 AM, Dave Rice <d...@dericed.com> wrote: > >> >> On May 17, 2018, at 10:22 AM, Clément Bœsch <u...@pkh.me> wrote: >> >> On Mon, May 14, 2018 at 05:50:25PM +0100, Derek Buitenhuis wrote: >> [...] >>> 1. Implement a formal CoC enforcement system. This has been mostly >>> copypasted >>> from VideoLAN's, and is meant as more of a blueprint. This will no >>> doubt >>> be controversial. >> >> So as mentioned already in the thread, the main issue is having a >> police/justice entity. I would say it needs to be separate from the >> development team (to maintain a power separation). Since such profile >> doesn't seem to be exactly common in the open source world, maybe we could >> externalize it. Does such a service exist with reasonable prices? Could we >> use our funds for this? I understand this may sound far-fetched, but who >> knows. > > CoC enforcement as a paid service sounds alarming. Though it might make sense > to consider people separate from the development team for the role. There are > likely many who would like to contribute to the FFmpeg project but not as a > developer who could consider such a role. > >> If such solution is not viable, we could fallback on the voting committee >> to elect/design a subgroup of itself (an odd number like 3 persons maybe?) >> to hold this moderation task for a period of 3 or 6 months, maybe 1 year. >> Then these members are automatically maintainer of the CoC for this period >> of time, and decide what to do with it. >> >> Just random thoughts, no hard opinion on it to be honest. > > I like this suggestion for a small committee to be tasked and trusted with > such actions. I consider that it might be easier to find rough consensus in > scenario a than in scenario b. > > a) the larger ffmpeg community finds consensus to appoint a CoC committee and > as needed the CoC committee finds consensus (as a small group) on how to > respond to concerns from the community and to implement the CoC. > > b) the larger ffmpeg community finds consensus on how to implement the CoC > directly each time there’s a concern from the community. > > Dave Rice > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel> _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
