Two ex-board members disagree. I have to side with Brian; the PSF board should have minimal say in how the developers develop.
Note, I'm fine with the board being the arbiter when someone disagrees with their ban though -- there's got to be a "higher authority" for appeals. But I don't agree that the board should be the decider on the initial ban. Maybe for additional oversight bans should be required to be reported to the board in a timely fashion. (Ain't I the lawyer. ;-) On Wed, May 3, 2017 at 12:48 PM, M.-A. Lemburg <m...@egenix.com> wrote: > Since this is a matter outside the realm of committers, the > PSF board will have to ultimately decide on any actions taken. > > The committers can report issues to the board and provide > information useful for their decisions, the bad actor also has > to be given a chance to respond to allegations and be heard. > Then the board can decide what to do. > > The two manuals should not be used or proposed as a guideline > for CoC handling, since they completely ignore the basic rights > of the alleged bad actors to a fair process. > > When I was a board member, we had already discussed this at the board > level and used to deal with such issues on a case by case basis, > which always included trying to contact the persons > in questions either directly or via a mediator. > > This has worked well and I don't see a good reason to suggest > using a less open and fair approach. > > Cheers, > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts (#1, May 03 2017) > >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ > >>> Python Database Interfaces ... http://products.egenix.com/ > >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ > ________________________________________________________________________ > > ::: We implement business ideas - efficiently in both time and costs ::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > http://www.malemburg.com/ > > > > > On 03.05.2017 21:28, Mariatta Wijaya wrote: > > Hi, > > > > First of all, sorry for bringing up an old thread. > > I know this is an uncomfortable topic, and I also wish that we can just > > avoid it, but ... I think we gotta do something about it. > > > > I understand why Brett did what he did, and I support his decision. > > > > I do agree with Raymond's point, that going forward, we should have > > a procedure in place, we all need to know what the rules are, and how to > > play by the rules. > > > > Communities like Django Project and Write The Docs have clear enforcement > > manuals on what to do in case of CoC violation: > > https://www.djangoproject.com/conduct/enforcement-manual/ > > http://www.writethedocs.org/code-of-conduct-response/ > > > > Can we adopt something like that to our community, or do we have this > > already? > > If it requires involvement with the PSF board, who could bring this to > > their attention? (I'm new I don't know how these things work yet) > > > > Brett's step-by-step guide above based on Raymond's proposal seems like a > > good start. > > Does that need to be approved by the board first? Or can we start by > > creating a PR to the devguide, and continue the discussion there? > > > > I also want to discuss what the different actions to be taken in case > > someone is being negative. > > In one of the mailing lists, the violator gets a warning for their first > > offense. > > What if their first offense is severe enough, maybe a warning may not be > > suitable? > > Do we (core developers) want to decide all of these ourselves, or do we > > leave it PSF board to decide? > > > > I just want to make sure that we are taking some actions going forward. > > > > > > > > Mariatta Wijaya > > > > On Sun, Apr 2, 2017 at 8:04 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > > >> On 3 April 2017 at 04:08, Brett Cannon <br...@python.org> wrote: > >>> On Sun, 2 Apr 2017 at 04:34 Paul Moore <p.f.mo...@gmail.com> wrote: > >>>> As a result, the public perception of a "code of conduct violation" is > >>>> that someone has harassed, or otherwise made a community member > >>>> uncomfortable, specifically because they don't conform to the > >>>> stereotypical norm. That's not necessarily what any specific code of > >>>> conduct might say, but it's how the public perceives such things (and > >>>> high-profile blog entries that expose exclusive behaviour, and cite > >>>> codes of conduct and how they help and where they fail to, simply > >>>> reinforce that perception). > >>>> > >>>> We may not like the fact that a simple term like "Code of Conduct" > >>>> gets appropriated in the public perception in such a way, but denying > >>>> the reality of it doesn't mean it doesn't happen. > >>> > >>> But based on how others are stating their views, I'm seem to be in the > >>> minority on this one. I'm fine with that as I can view it personally as > >>> political wordsmithing. For me the key is that if I'm going to shoulder > >> the > >>> burden of being a moderator I want to have the ability to keep > >> discussions > >>> open, respectful, and considerate. If that means that someone gets a > >> "CoC" > >>> label when they run afoul of those tenants by being mean while they get > >> an > >>> "persistently unproductive" label when they run afoul of those labels > in > >> how > >>> they communicate then I can live with that. > >> > >> I essentially agree with Brett here, but I also agree with MAL that at > >> least for now we can keep this to a simpler two level system where: > >> > >> 1. We write down explicit rules for encouraging productive, > >> collaborative discussions on PSF provided communication channels, > >> together with the process that channel moderators are advised to > >> follow when imposing temporary suspensions of posting privileges. We > >> then explicitly adopt those rules for the core Python communication > >> channels (python-dev, python-ideas, core-mentorship, the issue tracker > >> and meta-tracker, the python org on GitHub) by updating the Developer > >> Guide appropriately. The trigger for lifting suspensions imposed at > >> this level can just be that: a) the minimum time period specified by > >> the moderators has passed; b) the person suspended explicitly requests > >> that the channel moderators restore their posting privileges. > >> > >> Whether we call them "Rules for Active Participation" or something > >> else, this step gives channel moderators the explicit authority to > >> govern their channels according to their defined purpose, without > >> having to rely on the Code of Conduct as the sole mechanism for > >> ensuring that folks don't persist indefinitely in wasting other > >> people's time. > >> > >> 2. Anything that can't be handled through a temporary suspension of > >> posting privileges gets escalated to the elected PSF Board. For > >> example: > >> > >> - cases where folks feel they have been suspended unfairly by moderators > >> - cases where moderators believe that a temporary suspension should be > >> converted to a permanent ban > >> - cases where moderators believe that a ban from selected channels > >> should be converted to a ban from all PSF provided communication > >> channels > >> > >> This step ensures that channel moderators have a place to appeal for > >> assistance if behavioural management for particular individuals is > >> acting as a persistent drain on *their* time and energy, as well as > >> ensuring that there is a mechanism in place to request reviews of > >> moderator actions that seem to be unreasonable. > >> > >> The PSF Board has several desirable properties for this purpose: > >> > >> 1. As the responsible legal entity, the PSF is already the de facto > >> point of escalation for conduct related concerns on PSF provided > >> communication channels > >> 2. Since the switch to an open membership model for the PSF, the Board > >> is a genuinely representative body for the community at large > >> 3. As an elected body, the accountaibility mechanism for Board level > >> decision making is built into the PSF By-laws > >> 4. The Board membership list at any given point in time is public > >> information > >> 5. The Board is already set up to handle confidential discussion of > >> sensitive matters > >> 6. The Board are in a good position to request PSF staff assistance in > >> handling such matters when it seems appropriate to do so > >> > >> If we started out by formalising that existing two level model of > >> resource-specific moderators + the PSF (as represented by the Board), > >> it would then be up to the *Board* to decide if it needed a formal > >> process for delegating such discussions and decisions to a smaller > >> group. > >> > >> Regards, > >> Nick. > >> > >> -- > >> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > >> _______________________________________________ > >> python-committers mailing list > >> python-committers@python.org > >> https://mail.python.org/mailman/listinfo/python-committers > >> Code of Conduct: https://www.python.org/psf/codeofconduct/ > >> > > > > > > > > _______________________________________________ > > python-committers mailing list > > python-committers@python.org > > https://mail.python.org/mailman/listinfo/python-committers > > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > > > _______________________________________________ > python-committers mailing list > python-committers@python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
