Re: [openstack-dev] An alternative approach to enforcing expected election behaviour
James E. Blair wrote: I think our recent experience has shown that the fundamental problem is that not all of the members of our community knew what kind of behavior we expected around elections. That's understandable -- we had hardly articulated it. I think the best solution to that is therefore to articulate and communicate that. I believe Anita's proposal starts off by doing a very good job of exactly that, so I would like to see a final resolution based on that approach with very similar text to what she has proposed. That statement of expected behavior should then be communicated by election officials to all participants in announcements related to all elections. Those two simple acts will, I believe, suffice to address the problem we have seen. I do agree that a heavy bureaucracy is not necessary for this. Our community has a Code of Conduct established and administered by the Foundation. I think we should focus on minimizing additional process and instead try to make this effort slot into the existing framework as easily as possible by expecting the election officials to forward potential violations to the Foundation's Executive Director (or delegate) to handle as they would any other potential CoC violation. +1 The community code of conduct states: Respect the election process. Members should not attempt to manipulate election results. Open debate is welcome, but vote trading, ballot stuffing and other forms of abuse are not acceptable. Maybe just clarifying what we mean by open debate and giving examples of what we would consider other forms of abuse in the context of the TC elections is actually sufficient. Then voters can judge abuse on their own in their vote (reputational pressure) *and* we have an established process (the alleged violation of the community code of conduct) to escalate to in case we really need to (institutional pressure). I think the first part of Anita's draft captures that very well, so maybe that's all we need. I really think that documenting and better communicating expectations will actually avoid problems in the future. Regards, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] An alternative approach to enforcing expected election behaviour
James E. Blair wrote: I think our recent experience has shown that the fundamental problem is that not all of the members of our community knew what kind of behavior we expected around elections. That's understandable -- we had hardly articulated it. I think the best solution to that is therefore to articulate and communicate that. I believe Anita's proposal starts off by doing a very good job of exactly that, so I would like to see a final resolution based on that approach with very similar text to what she has proposed. That statement of expected behavior should then be communicated by election officials to all participants in announcements related to all elections. Those two simple acts will, I believe, suffice to address the problem we have seen. I do agree that a heavy bureaucracy is not necessary for this. Our community has a Code of Conduct established and administered by the Foundation. I think we should focus on minimizing additional process and instead try to make this effort slot into the existing framework as easily as possible by expecting the election officials to forward potential violations to the Foundation's Executive Director (or delegate) to handle as they would any other potential CoC violation. Thierry Carrez wrote: +1 The community code of conduct states: Respect the election process. Members should not attempt to manipulate election results. Open debate is welcome, but vote trading, ballot stuffing and other forms of abuse are not acceptable. Maybe just clarifying what we mean by open debate and giving examples of what we would consider other forms of abuse in the context of the TC elections is actually sufficient. Then voters can judge abuse on their own in their vote (reputational pressure) *and* we have an established process (the alleged violation of the community code of conduct) to escalate to in case we really need to (institutional pressure). I think the first part of Anita's draft captures that very well, so maybe that's all we need. I really think that documenting and better communicating expectations will actually avoid problems in the future. Absolutely agreed with jeblair and ttx here, that communicating expectations clearly is the key. However I think that the choice between relying on reputational versus institutional pressure for enforcement should be an either-or proposition, in order for it to be most effective. The potential problem with reputational being the default, then falling back to institutional pressure in extremis, is that folks may read something into the absence of an escalation. e.g. the openstack officialdom doesn't seem to have done anything about this practice, so it must be ok IMHO reliance on the wisdom-of-crowds for enforcement works best when the crowd explicitly knows that it's the last line of defense. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] An alternative approach to enforcing expected election behaviour
Eoghan Glynn egl...@redhat.com writes: TL;DR: how about we adopt a soft enforcement model, relying on sound judgement and good faith within the community? Thank you very much for bringing this up and proposing it to the TC. As others have suggested, having a concrete alternative is very helpful in revealing both the positive and negative aspects of a proposal. I think our recent experience has shown that the fundamental problem is that not all of the members of our community knew what kind of behavior we expected around elections. That's understandable -- we had hardly articulated it. I think the best solution to that is therefore to articulate and communicate that. I believe Anita's proposal starts off by doing a very good job of exactly that, so I would like to see a final resolution based on that approach with very similar text to what she has proposed. That statement of expected behavior should then be communicated by election officials to all participants in announcements related to all elections. Those two simple acts will, I believe, suffice to address the problem we have seen. I do agree that a heavy bureaucracy is not necessary for this. Our community has a Code of Conduct established and administered by the Foundation. I think we should focus on minimizing additional process and instead try to make this effort slot into the existing framework as easily as possible by expecting the election officials to forward potential violations to the Foundation's Executive Director (or delegate) to handle as they would any other potential CoC violation. -Jim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] An alternative approach to enforcing expected election behaviour
TL;DR: how about we adopt a soft enforcement model, relying on sound judgement and good faith within the community? Hi Folks, I'm concerned that the expected election behaviour review[1] is not converging on the optimal approach, partially due to the initial concentration on the procedural aspects of the proposal. This concentration was natural enough, due to shortcomings such as the lack of any provision for a right of reply, or the fuzziness around who was capable of deciding a violation had occurred and imposing the stiff penalties envisaged. However, I think we should take a step back at this stage and reconsider the whole approach. Looking at this in the round, as I see it, the approach mooted seems to suffer from a fundamental flaw. Specifically, in holding individuals to the community code of conduct[2] in a very *strict* sense (under pain of severe career damage), when much of that code is written in an aspirational style, and so is not very suitable for use as an *objective* standard. The reference to the spirit of the OpenStack ideals ideals is even more problematic in that sense. Ideals by their nature are *idealized* versions of reality. So IMHO it's not workable to infuse an aspiration to meet these laudable ideals, with the language of abuse, violations, investigation, punishment etc. In fact it strikes me as a tad Orwellian to do so. So I wanted to throw an alternative idea out onto the table ... How about we rely instead on the values and attributes that actually make our community strong? Specifically: maturity, honesty, and a self-correcting nature. How about we simply require that each candidate for a TC or PTL election gives a simple undertaking in their self-nomination mail, along the lines of: I undertake to respect the election process, as required by the community code of conduct. I also undertake not to engage in campaign practices that the community has considered objectionable in the past, including but not limited to, unsolicited mail shots and private campaign events. If my behavior during this election period does not live up to those standards, please feel free to call me out on it on this mailing list and/or withhold your vote. We then rely on: (a) the self-policing nature of an honest, open community and: (b) the maturity and sound judgement within that community giving us the ability to quickly spot and disregard any frivolous reports of mis-behavior So no need for heavy-weight inquisitions, no need to interrupt the election process, no need for handing out of stiff penalties such as termination of membership. Instead, we simply rely on good faith and sound judgement within the community. TBH I think we're pretty good at making ourselves heard when needs be, and also pretty good at filtering through the noise. So I would trust the electorate to apply their judgement, filter out those reports of bad practice that they consider frivolous or tending to make mischief, or conversely to withhold their vote if they consider the practice reported to be unacceptable. If someone has already cast their vote when the report of some questionable behavior surfaces, well so be it. The electorate has a long memory and most successful candidates end up running again for subsequent elections (e.g. a follow-on term as PTL, or for the TC). The key strength of this alternative approach IMO is that it directly relies on the *actual* values of the community, as opposed to attempting to codify those values, a priori. Just my $0.02 ... Cheers, Eoghan [1] https://review.openstack.org/98675 [2] http://www.openstack.org/legal/community-code-of-conduct ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] An alternative approach to enforcing expected election behaviour
On Mon, Jun 16, 2014 at 05:04:51AM -0400, Eoghan Glynn wrote: How about we rely instead on the values and attributes that actually make our community strong? Specifically: maturity, honesty, and a self-correcting nature. How about we simply require that each candidate for a TC or PTL election gives a simple undertaking in their self-nomination mail, along the lines of: I undertake to respect the election process, as required by the community code of conduct. I also undertake not to engage in campaign practices that the community has considered objectionable in the past, including but not limited to, unsolicited mail shots and private campaign events. If my behavior during this election period does not live up to those standards, please feel free to call me out on it on this mailing list and/or withhold your vote. I like this proposal because it focuses on the carrot rather than the stick, which is ultimately better for community cohesiveness IMHO. It is already part of our community ethos that we can call people out to publically debate / stand up justify any all issues affecting the project whether they be related to the code, architecture, or non-technical issues such as electioneering behaviour. We then rely on: (a) the self-policing nature of an honest, open community and: (b) the maturity and sound judgement within that community giving us the ability to quickly spot and disregard any frivolous reports of mis-behavior So no need for heavy-weight inquisitions, no need to interrupt the election process, no need for handing out of stiff penalties such as termination of membership. Before jumping headlong for a big stick to whack people with, I think I'd expect to see examples of problems we've actually faced (as opposed to vague hypotheticals), and a clear illustration that a self-policing approach to the community interaction failed to address them. I've not personally seen/experianced any problems that are so severe that they'd suggest we need the ability to kick someone out of the community for sending email ! Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] An alternative approach to enforcing expected election behaviour
On Mon, 2014-06-16 at 10:56 +0100, Daniel P. Berrange wrote: On Mon, Jun 16, 2014 at 05:04:51AM -0400, Eoghan Glynn wrote: How about we rely instead on the values and attributes that actually make our community strong? Specifically: maturity, honesty, and a self-correcting nature. How about we simply require that each candidate for a TC or PTL election gives a simple undertaking in their self-nomination mail, along the lines of: I undertake to respect the election process, as required by the community code of conduct. I also undertake not to engage in campaign practices that the community has considered objectionable in the past, including but not limited to, unsolicited mail shots and private campaign events. If my behavior during this election period does not live up to those standards, please feel free to call me out on it on this mailing list and/or withhold your vote. I like this proposal because it focuses on the carrot rather than the stick, which is ultimately better for community cohesiveness IMHO. I like it too. A slight tweak of that would be to require candidates to sign the pledge publicly via an online form. We could invite the community as a whole to sign it too in order to have candidates' supporters covered. It is already part of our community ethos that we can call people out to publically debate / stand up justify any all issues affecting the project whether they be related to the code, architecture, or non-technical issues such as electioneering behaviour. We then rely on: (a) the self-policing nature of an honest, open community and: (b) the maturity and sound judgement within that community giving us the ability to quickly spot and disregard any frivolous reports of mis-behavior So no need for heavy-weight inquisitions, no need to interrupt the election process, no need for handing out of stiff penalties such as termination of membership. Before jumping headlong for a big stick to whack people with, I think I'd expect to see examples of problems we've actually faced (as opposed to vague hypotheticals), and a clear illustration that a self-policing approach to the community interaction failed to address them. I've not personally seen/experianced any problems that are so severe that they'd suggest we need the ability to kick someone out of the community for sending email ! Indeed. This discussion is happening in a vacuum for many people who do not know the details of the private emails and private campaign events which happened in the previous cycle. The only one I know of first hand was a private email where the recipients quickly responded saying the email was out of line and the original sender apologized profusely. People can make mistakes in good faith and if we can deal with it quickly and maturely as a community, all the better. In this example, the sender's apology could have bee followed up with look, here's our code of conduct; sign it now, respect it in the future, and let that be the end of the matter. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] An alternative approach to enforcing expected election behaviour
On Mon, Jun 16, 2014 at 9:41 AM, Mark McLoughlin mar...@redhat.com wrote: On Mon, 2014-06-16 at 10:56 +0100, Daniel P. Berrange wrote: On Mon, Jun 16, 2014 at 05:04:51AM -0400, Eoghan Glynn wrote: How about we rely instead on the values and attributes that actually make our community strong? Specifically: maturity, honesty, and a self-correcting nature. How about we simply require that each candidate for a TC or PTL election gives a simple undertaking in their self-nomination mail, along the lines of: I undertake to respect the election process, as required by the community code of conduct. I also undertake not to engage in campaign practices that the community has considered objectionable in the past, including but not limited to, unsolicited mail shots and private campaign events. If my behavior during this election period does not live up to those standards, please feel free to call me out on it on this mailing list and/or withhold your vote. I like this proposal because it focuses on the carrot rather than the stick, which is ultimately better for community cohesiveness IMHO. I like it too. A slight tweak of that would be to require candidates to sign the pledge publicly via an online form. We could invite the community as a whole to sign it too in order to have candidates' supporters covered. +1 I'm less worried about the candidates, since they are in the spotlight during the election. I'm more worried about supporters getting carried away in their enthusiasm or not understanding how much (and why) the community values open participation. It is already part of our community ethos that we can call people out to publically debate / stand up justify any all issues affecting the project whether they be related to the code, architecture, or non-technical issues such as electioneering behaviour. We then rely on: (a) the self-policing nature of an honest, open community and: (b) the maturity and sound judgement within that community giving us the ability to quickly spot and disregard any frivolous reports of mis-behavior So no need for heavy-weight inquisitions, no need to interrupt the election process, no need for handing out of stiff penalties such as termination of membership. Before jumping headlong for a big stick to whack people with, I think I'd expect to see examples of problems we've actually faced (as opposed to vague hypotheticals), and a clear illustration that a self-policing approach to the community interaction failed to address them. I've not personally seen/experianced any problems that are so severe that they'd suggest we need the ability to kick someone out of the community for sending email ! Indeed. This discussion is happening in a vacuum for many people who do not know the details of the private emails and private campaign events which happened in the previous cycle. The only one I know of first hand was a private email where the recipients quickly responded saying the email was out of line and the original sender apologized profusely. People can make mistakes in good faith and if we can deal with it quickly and maturely as a community, all the better. In this example, the sender's apology could have bee followed up with look, here's our code of conduct; sign it now, respect it in the future, and let that be the end of the matter. I agree that the penalties in the original proposal went too far. I also think it's a good point that many people don't know the details from the last cycle, so I think some specific guidance on how to report issues so they can be addressed formally is an important aspect of this proposal. Doug Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] An alternative approach to enforcing expected election behaviour
On Mon, 2014-06-16 at 10:56 +0100, Daniel P. Berrange wrote: On Mon, Jun 16, 2014 at 05:04:51AM -0400, Eoghan Glynn wrote: How about we rely instead on the values and attributes that actually make our community strong? Specifically: maturity, honesty, and a self-correcting nature. How about we simply require that each candidate for a TC or PTL election gives a simple undertaking in their self-nomination mail, along the lines of: I undertake to respect the election process, as required by the community code of conduct. I also undertake not to engage in campaign practices that the community has considered objectionable in the past, including but not limited to, unsolicited mail shots and private campaign events. If my behavior during this election period does not live up to those standards, please feel free to call me out on it on this mailing list and/or withhold your vote. I like this proposal because it focuses on the carrot rather than the stick, which is ultimately better for community cohesiveness IMHO. I like it too. A slight tweak of that would be to require candidates to sign the pledge publicly via an online form. We could invite the community as a whole to sign it too in order to have candidates' supporters covered. Fair point, that would work for me also. It is already part of our community ethos that we can call people out to publically debate / stand up justify any all issues affecting the project whether they be related to the code, architecture, or non-technical issues such as electioneering behaviour. We then rely on: (a) the self-policing nature of an honest, open community and: (b) the maturity and sound judgement within that community giving us the ability to quickly spot and disregard any frivolous reports of mis-behavior So no need for heavy-weight inquisitions, no need to interrupt the election process, no need for handing out of stiff penalties such as termination of membership. Before jumping headlong for a big stick to whack people with, I think I'd expect to see examples of problems we've actually faced (as opposed to vague hypotheticals), and a clear illustration that a self-policing approach to the community interaction failed to address them. I've not personally seen/experianced any problems that are so severe that they'd suggest we need the ability to kick someone out of the community for sending email ! Indeed. This discussion is happening in a vacuum for many people who do not know the details of the private emails and private campaign events which happened in the previous cycle. The only one I know of first hand was a private email where the recipients quickly responded saying the email was out of line and the original sender apologized profusely. People can make mistakes in good faith and if we can deal with it quickly and maturely as a community, all the better. Exactly. Most realistic missteps that I can imagine could be dealt with by a simple calling out of the error, then moving on quickly. Simple, lightweight, a teachable moment. No need for heavy-handed inquisitions IMHO if we trust our own instincts as a community. Cheers, Eoghan In this example, the sender's apology could have bee followed up with look, here's our code of conduct; sign it now, respect it in the future, and let that be the end of the matter. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
