| Message ID | 720090b2-6822-268b-d3d3-6c652e689094@mail.de |
|---|---|
| State | New |
| Headers | show |
On Thu, 22 Nov 2018 at 19:02, Thilo Borgmann <thilo.borgmann@mail.de> wrote: > > Please note that this survey is _not_ meant to be a vote about the > proposal. It is to > determine if we should actually have a refinement/vote on instantiating > such a > community committee - depending on the community's point of view. > Spamming (which this would certainly be a textbook definition of) every subscriber ever (including those who forgot) is unacceptable. +Further on it is to impose any sanctions related to violations of the code of > +conduct only if these incidents are brought up to its attention from directly > +involved parties of such an incident. > > Violations should be limited to publicly logged IRC channels or the ML. Otherwise without proof this will end up as a "but they said" situation. ++ at subheading <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel> Committee members > + > +The community committee consists of three elected individuals. Committee members are > +elected for a period of one year and are automatically removed from the committee after > +that period. Reelection of committee members for the following period is possible. > > Three members is far too low and would be prone to bias. 5 or 7 would be better. > + > +If for any reason a current member of the committee wishes to leave the committee, the > +whole committee is to be reelected. No former committee members having left the committee > +on their own wish can be a candidate for the successor committee. > > That last sentence is random. +The vote has to implement a direct, free, equal and secret election. > +The results are to be publicly available. > +The election should be completed not later than the end of the ongoing period. > +Any community member can call on itself or any other person to be a candidate for an election. > > What if a majority of the committee is biased and bans everyone they disagree with to take over the project? They certainly could. What if the committee's decision is something the majority of the developers disagree with? This is why I'm against formalizing such prodecures. They're too inflexible and absolute, and end up being abused or overused (like videolan's weekly temporary bannings I've heard of). Furthermore why do you bring this up now at all? We haven't had accidents of this nature in quite some time. In fact the last time it was the ML admin's random incorrect decision to block a discussion which ended up being a problem that everyone disagreed with. And that was 11 months ago.
> > > What if a majority of the committee is biased and bans everyone they > disagree with to take over the project? They certainly could. > What if the committee's decision is something the majority of the > developers disagree with? > > This is why I'm against formalizing such prodecures. They're too inflexible > and absolute, and end up being abused or overused (like videolan's weekly > temporary bannings I've heard of). > Furthermore why do you bring this up now at all? We haven't had accidents > of this nature in quite some time. In fact the last time it was the ML > admin's random incorrect decision to block a discussion which ended up > being a problem that everyone disagreed with. And that was 11 months ago Thank you for confirming to the rest of the community why we need a committee and proper Code of Conduct like other comparable Open Source projects. Kieran
Am 22.11.18 um 22:58 schrieb Rostislav Pehlivanov: > On Thu, 22 Nov 2018 at 19:02, Thilo Borgmann <thilo.borgmann@mail.de> wrote: > >> >> Please note that this survey is _not_ meant to be a vote about the >> proposal. It is to >> determine if we should actually have a refinement/vote on instantiating >> such a >> community committee - depending on the community's point of view. >> > > Spamming (which this would certainly be a textbook definition of) every > subscriber ever (including those who forgot) is unacceptable. All subscribers are per definition interested in FFmpeg development. I don't see how this should be spam in general to this audience. > +Further on it is to impose any sanctions related to violations of the code of >> +conduct only if these incidents are brought up to its attention from directly >> +involved parties of such an incident. >> >> Violations should be limited to publicly logged IRC channels or the ML. > Otherwise without proof this will end up as a "but they said" situation. Agree. > ++ at subheading <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel> > Committee members >> + >> +The community committee consists of three elected individuals. Committee members are >> +elected for a period of one year and are automatically removed from the committee after >> +that period. Reelection of committee members for the following period is possible. >> >> Three members is far too low and would be prone to bias. 5 or 7 would be > better. A question I discussed with many others. I don't have a strong opinion, 3/5/7 have always been the options. Feel free to put that to discussion again. >> + >> +If for any reason a current member of the committee wishes to leave the committee, the >> +whole committee is to be reelected. No former committee members having left the committee >> +on their own wish can be a candidate for the successor committee. >> >> That last sentence is random. Not quite. It prevents "blocking" attempts by stepping back and getting elected again. The whole committee is to be voted upon again to prevent biasing attempts within the committee. Or I might see why you think this could not happen. > +The vote has to implement a direct, free, equal and secret election. >> +The results are to be publicly available. >> +The election should be completed not later than the end of the ongoing period. >> +Any community member can call on itself or any other person to be a candidate for an election. >> >> What if a majority of the committee is biased and bans everyone they > disagree with to take over the project? They certainly could. > What if the committee's decision is something the majority of the > developers disagree with? Nothing prevents the community to release the committee it instantiated. A community vote on (this or whatever) is not object to the powers of the committee. > This is why I'm against formalizing such prodecures. They're too inflexible > and absolute, and end up being abused or overused (like videolan's weekly > temporary bannings I've heard of). Didn't heard of these by now. However, in discussing with people, it revealed there are two ways to go with that. Either, you give a set of rules and define everything in these and can't handle anything else. Or, you set one rule to be <put wanted behavior here> and have each thing in relation to that. Experience says, the first possibility comes with people navigating on the bleeding edge of the rules exploiting every grey zone there might be. The second comes with people having an other interpretation of the "one rule" in contrast to the committee. Well, I prefer the second way. But this question you can also put to discussion again. > Furthermore why do you bring this up now at all? We haven't had accidents > of this nature in quite some time. In fact the last time it was the ML > admin's random incorrect decision to block a discussion which ended up > being a problem that everyone disagreed with. And that was 11 months ago. You have been at VDD, Rostislav. We had this session, people made this a topic, I agreed on summing up and sending it to the list. I've not stumbled across such incidents lately, too. However, I by far do not read every mail here or do watch IRC at all - people still having this impression are a good enough reason for me. Personally, even if these accidents would have ceased to happen - history tells us we might use a better way of dealing with it, since CoC violations are an ever repeating thing to happen. -Thilo
On Thu, 22 Nov 2018, at 22:58, Rostislav Pehlivanov wrote: > This is why I'm against formalizing such prodecures. They're too inflexible > and absolute, Enforcement depends on who is enforcing it. Hence elections. > and end up being abused or overused (like videolan's weekly > temporary bannings I've heard of). <ref_needed> We banned 2 times 1 person from IRC 24hours, and banned someone once from the mailing-list, in the many years (7?) that our CoC existed. Please don't spread misinformation. I don't see how that is abusing or overusing...
tor 2018-11-22 klockan 21:58 +0000 skrev Rostislav Pehlivanov: > > On Thu, 22 Nov 2018 at 19:02, Thilo Borgmann <thilo.borgmann@mail.de> wrote: > +The vote has to implement a direct, free, equal and secret election. > > +The results are to be publicly available. > > +The election should be completed not later than the end of the ongoing period. > > +Any community member can call on itself or any other person to be a candidate for an election. > > What if a majority of the committee is biased and bans everyone they > disagree with to take over the project? They certainly could. > What if the committee's decision is something the majority of the > developers disagree with? > > This is why I'm against formalizing such prodecures. They're too inflexible > and absolute, and end up being abused or overused (like videolan's weekly > temporary bannings I've heard of). > Furthermore why do you bring this up now at all? We haven't had accidents > of this nature in quite some time. In fact the last time it was the ML > admin's random incorrect decision to block a discussion which ended up > being a problem that everyone disagreed with. And that was 11 months ago. The point of stuff like this is to have something in place *before* nasty things happen. Coming from a country with a strong non-profit organization culture (Sweden), it's actually quite striking how little "everyday democracy" experience a lot of free software people seem to have. While I'm in here I have a small suggestion: talking is better than writing when it comes to interpersonal conflicts. Using Mumble or Jingle or whatever and getting the relevant people to talk can be a good way to avoid more drastic measures. Unless of course someone's just being an ass to be an ass, but I haven't noticed that yet on here. /Tomas
On 24.11.2018 16:32, Tomas Härdin wrote: > [...] > > While I'm in here I have a small suggestion: talking is better than > writing when it comes to interpersonal conflicts. Using Mumble or > Jingle or whatever and getting the relevant people to talk can be a > good way to avoid more drastic measures. Unless of course someone's > just being an ass to be an ass, but I haven't noticed that yet on here. Seems like a good idea. And the talking could be moderated by a person neutral to the conflict. Regards, Tobias
Hi again, > I'm very sorry that it took me so long to send this to the list, finally. > Since this is an everlasting topic for years, I wanted to deal > thoroughly with it to have a chance to actually influence the situation. > > Like in many previous years/sessions about FFmpeg development, the topic of > hostility at the ML and IRC channel was discussed yet another time. There > have been several voices at this year's session that are still unhappy > with the current hostility in the FFmpeg community. So this point has been > discussed in the audience for a while. However, there has also been a voice > claiming that the current situation and regulation by our CoC is ok and working. > > According to my experience, these discussions lead to two ends. First, > is considering the FFmpeg community to be a hostile environment shared by a > majority of the community so that any further thoughts to try to change this are > valid or not? Second, assuming it is a majority that dislikes current hostility, > what to do about it to improve the situation? > > Long ago, JB made a proposal to overcome this by getting a community committee > to act upon hostile behavior in our environment and sanction the respective > authors. This proposal has been brought up again regarding the question of how > to proceed and like in the previous years, this proposal raised no rejections > from anybody present (this and in the previous years). > > In the end, the outcome of this VDDs FFmpeg session has been that I bring this > proposal to the mailing list, finally. Therefore, I took the time to talk to > several people not only about the proposal itself but also about the experience > of other communities having such a committee driven mechanism of dealing with > CoC conflicts. From that the idea emerged to get an overview of the actual community > opinion of things is to conduct a simple survey about this question. So this is > exactly what I'd like to do next to giving the mere proposal. > > The proposal of a community committee summarized: > > - A committee is to be created consisting of community members that are voted > into it > - This committee can (upon request) sanction violations of our CoC by its given > powers > - The committee is object to reelection every year > > A more detailed possible implementation of the proposal is attached as a patch to > our developers documentation. The survey is done to get an idea of what the community > thinks about that matter and its proposed solution. > > The survey shall be conducted for everyone to participate freely, so a simple > thread on the mailing list would hardly be suitable and will most likely end in > endless discussions. To help with that, we've set up a survey that can be done completely > anonymously by sending out private tokens to all possible participants. Even the survey > admins cannot map given survey answers to a person/token. > > Please note that this survey is _not_ meant to be a vote about the proposal. It is to > determine if we should actually have a refinement/vote on instantiating such a > community committee - depending on the community's point of view. > > I will start this survey and sending out tokens directly to every subscriber of > the ffmpeg-devel mailing list on this Friday, Nov 23rd. If you don't want to > participate in the survey, you can send me a private mail before that data to > exclude your mail address from the participants lists. Afterwards you can click > the link in the mails to opt out of the survey yourself. The survey will end on > Mondday, Dez 3nd (a little more than a week). Afterwards, I will post the results > of the survey here in this thread. > > I'd really appreciate participation in the survey from everyone. I'd like to ask to file > just one survey for every mail address you might have registered here - you can opt-out > or just ignore additional mails. I'm sorry for spam for everyone not reading this thread. > Many thanks to the KDE community and Lydia in particular for discussion and supporting us > with the survey infrastructure. the survey ended on Monday, results are given below. It has been criticized that the survey does not cover more detailed questions about the folks who do not think that the community is currently hostile. Several people thought about the survey design and yet that part was not covered. We might go for another survey on that part if people really want it - I guess we can run another one on the KDE infrastructure. Not to perceive the community to be hostile does not mean to reject a community committee (or changes to the CoC or other related actions), though. Also, that Q2 to Q4 only appeared if the previous answer was yes (in the sense of a hostile environment) has been criticized. Well, the assumption was that if you feel no to be your answer to a question, all follow-ups would not fit into that - why to ask if you're affected if you don't see a hostile community? That this might also have been done differently, is out of the question. Easier to say afterwards, though. And like all the criticism there has been, it might be helpful for the future so thank you if you had send me feedback about the survey! These are the results. I'll leave interpretation of that open for discussion and ask the community how to proceed with the results. The results are: There have been 3 binary questions and a free form text for suggestions as alternatives to the proposed committee. I tried to summarize below. If anyone is interested in all the full texts, that can for sure be setup somehow. There were 1891 mail addresses on ffmpeg-devel, I removed one subscriber manually, 19 opted out on their own, some 90-100 mails bounced during sending the tokens, of the remaining people 196 surveys have been filed giving roughly 10% participation. Q1: Do you consider the FFmpeg community currently to be a hostile environment? Yes: 67 (34.18%) No: 129 (65.82%) Q2: Is your participation in the project influenced in a negative way by this level of hostility? Yes: 58 (86.57%) No: 9 (13.43%) Q3: Do you think a community driven committee would be a valid way of improving the situation? Yes: 47 (81.03%) No: 11 (18.97%) Q4: Do you see any alternative approach? (This was available to all 11 "No" records from Q3) - blame hostile people publicly - better newbie support, be more welcoming in general - not ignoring patches, be more gentle to users trying to fix shortcomings - do more specific CoC - just ignore hostile people - committee might raise two tier community - clarification of decision process in the community - committee might be received as "thought policing" (If I forgot an important aspect for anyone, feel free to just send a mail to the discussion or a private mail to me if you wish to keep that thing private as all of the above are) As said above, I've send the results. I'm not going to post my own (biased) thoughts right now in this post, I'll just join the discussion afterwards. Thanks, Thilo
diff --git a/doc/developer.texi b/doc/developer.texi index 5c342c9106..5c4014b7de 100644 --- a/doc/developer.texi +++ b/doc/developer.texi @@ -451,6 +451,70 @@ instead and point them in the right direction. Finally, keep in mind the immortal words of Bill and Ted, "Be excellent to each other." +@chapter Community Committee + +The objective of the community committee is to sustain an environment as described +by the code of conduct. It is to protect the dignity of each member of the community +and to stop personal harassment of any kind. It is not to interfere with any other +aspects of the development process. + +Further on it is to impose any sanctions related to violations of the code of +conduct only if these incidents are brought up to its attention from directly +involved parties of such an incident. + +With respect to these conditions, the committee is entitled to: + +@itemize +@item + Address violations publically +@item + Conduct a private hearing of involved parties +@item + Temporarily or permanently ban individuals from the mailing lists and IRC channels +@item + Temporarily or permanently cease commit rights for any project repository +@end itemize + +It is up to the committee to decide in a case-to-case manner about which sanctions +are suitable to apply in conformance with its entitlement given above. + +The committee will publically announce each and every decision upon incidents brought +to its attention including sanctioning, if any, within one week after an incidents has +been brought up to its attention. + +@subheading Committee members + +The community committee consists of three elected individuals. Committee members are +elected for a period of one year and are automatically removed from the committee after +that period. Reelection of committee members for the following period is possible. + +If for any reason a current member of the committee wishes to leave the committee, the +whole committee is to be reelected. No former committee members having left the committee +on their own wish can be a candidate for the successor committee. + +@subheading Committee election + +The election of all committee members is conducted by the community. +All community members that meet at least one of the following requirements are eligible to vote: + +@itemize +@item + Having commit rights for any project repository +@item + Being a maintainer as listed in @file{MAINTAINERS} +@item + Being among the 100 most active contributors during the past year, determined by: + @code{<some git command to be specified, TBD> | head -100} +@end itemize + +A Condorcet method @uref{http://somewhere.org/something, TBD} will be used to perform +an election of the committee members. + +The vote has to implement a direct, free, equal and secret election. +The results are to be publicly available. +The election should be completed not later than the end of the ongoing period. +Any community member can call on itself or any other person to be a candidate for an election. + @anchor{Submitting patches} @chapter Submitting patches
Hi all, I'm very sorry that it took me so long to send this to the list, finally. Since this is an everlasting topic for years, I wanted to deal thoroughly with it to have a chance to actually influence the situation. Like in many previous years/sessions about FFmpeg development, the topic of hostility at the ML and IRC channel was discussed yet another time. There have been several voices at this year's session that are still unhappy with the current hostility in the FFmpeg community. So this point has been discussed in the audience for a while. However, there has also been a voice claiming that the current situation and regulation by our CoC is ok and working. According to my experience, these discussions lead to two ends. First, is considering the FFmpeg community to be a hostile environment shared by a majority of the community so that any further thoughts to try to change this are valid or not? Second, assuming it is a majority that dislikes current hostility, what to do about it to improve the situation? Long ago, JB made a proposal to overcome this by getting a community committee to act upon hostile behavior in our environment and sanction the respective authors. This proposal has been brought up again regarding the question of how to proceed and like in the previous years, this proposal raised no rejections from anybody present (this and in the previous years). In the end, the outcome of this VDDs FFmpeg session has been that I bring this proposal to the mailing list, finally. Therefore, I took the time to talk to several people not only about the proposal itself but also about the experience of other communities having such a committee driven mechanism of dealing with CoC conflicts. From that the idea emerged to get an overview of the actual community opinion of things is to conduct a simple survey about this question. So this is exactly what I'd like to do next to giving the mere proposal. The proposal of a community committee summarized: - A committee is to be created consisting of community members that are voted into it - This committee can (upon request) sanction violations of our CoC by its given powers - The committee is object to reelection every year A more detailed possible implementation of the proposal is attached as a patch to our developers documentation. The survey is done to get an idea of what the community thinks about that matter and its proposed solution. The survey shall be conducted for everyone to participate freely, so a simple thread on the mailing list would hardly be suitable and will most likely end in endless discussions. To help with that, we've set up a survey that can be done completely anonymously by sending out private tokens to all possible participants. Even the survey admins cannot map given survey answers to a person/token. Please note that this survey is _not_ meant to be a vote about the proposal. It is to determine if we should actually have a refinement/vote on instantiating such a community committee - depending on the community's point of view. I will start this survey and sending out tokens directly to every subscriber of the ffmpeg-devel mailing list on this Friday, Nov 23rd. If you don't want to participate in the survey, you can send me a private mail before that data to exclude your mail address from the participants lists. Afterwards you can click the link in the mails to opt out of the survey yourself. The survey will end on Mondday, Dez 3nd (a little more than a week). Afterwards, I will post the results of the survey here in this thread. I'd really appreciate participation in the survey from everyone. I'd like to ask to file just one survey for every mail address you might have registered here - you can opt-out or just ignore additional mails. I'm sorry for spam for everyone not reading this thread. Many thanks to the KDE community and Lydia in particular for discussion and supporting us with the survey infrastructure. Thanks, Thilo From 777631a9181ccb549170409b7cf9c5934ab6aeb8 Mon Sep 17 00:00:00 2001 From: Thilo Borgmann <thilo.borgmann@mail.de> Date: Thu, 22 Nov 2018 19:49:18 +0100 Subject: [PATCH] doc/developers: Add Community Committee --- doc/developer.texi | 64 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+)