On 3/26/15 1:46 PM, Noah Slater wrote: > Oh, thanks for the input Shane! > > I don't want to make the punitive measures stuff too complex. It should be > simple and easy to understand for both those who want protection from > harassment and so on, and those who've been spoken to about adjusting their > conduct. > > A strikes system is one idea. So individuals get warnings for minor things, > and are told to adjust. > > Beyond that, we might consider several things: > > - Temporary removal from a mailing list (or whether the behaviour is > occurring) > - Longer periods of removal or banning from the same
I would expect both of the above every PMC could/should do for themselves. I.e. the PMC and private@ should be the reporting path, and the PMC can just do the above as they see the need. Importantly, I think most people would look to PMCs to document their own systems. Having an ASF-wide "sample policy" would be good, but I'm betting some PMCs would still use their own details > - Removal from a PMC, or revocation of committer or member status PMCs should be able to remove their own committers, although one would hope that is rare. Anything dealing with removing or otherwise censuring PMC members or ASF Members would need to be done by the board. > People should know that we are perfectly prepared to expel individuals from > our community who do not work with us to keep it a safe and welcoming > environment for everybody. "Our community" also points to setting the expectation that the group closest to the community should be enforcing these - hence, the PMCs whenever possible should police their own projects. > > Removing from PMC and revocation of committer status can be done by PMCs > themselves, should they be the ones enforcing the CoC. If not that, a > recommendation from the Community PMC to the board to take the appropriate > action. And failing that, for the Board itself to step in and take such > action. Yup. - Shane > > > On Wed, 25 Mar 2015 at 18:20 Shane Curcuru <a...@shanecurcuru.org> wrote: > >> On 3/25/15 12:00 PM, Noah Slater wrote: >>> Yep, thanks for the reply. I'm not sure how to handle the governance side >>> of this. But I'm sure we can come to an agreement on this list soon. >> >> Discussing here makes sense; it's public and there are plenty of helpful >> voices that are likely to participate; plus this is a key thing we >> should ensure that newcomers to our communities see. This group should >> definitely be able to get consensus on any updates and be able to >> publish them - if board or President have issues, I'm sure they'll >> weight in about the documentation if needed. >> >> In terms of escalation and reporting, that's tricky, because we are both >> a Delaware corporation and a volunteer-run community. >> >> - For issues within one project, the best first place to escalate is >> that PMC's private@ list, if the reporter is comfortable doing so. >> >> - Otherwise, I'd say the private@community.a.o list would be an >> effective place to report/escalate, because there are people here who >> could help working within the community. >> >> - Beyond that, we need board or President to agree on whatever further >> "formal" contact address or escalation path we will support. Barring >> anything more specific, I'd start the recommendation being board@. >> >> In terms of enforcement, there are plenty of different people >> (especially Members) at the ASF who can help with enforcement on a >> community scale, so any ways we can make it more obvious for how to >> contact them/ask for help is good. >> >> But in terms of true enforcement, that goes to the board. Since PMCs >> report to the board, it's up to the board to enforce any serious issues, >> if it comes to that. Specific issues with infra/press/brand, and >> probably conferences (i.e. not issues within an Apache project) should >> escalate to President@, because those officers report to the President. >> >> - Shane >> >> P.S. This is a good topic - reminds me of a question recently on >> foundations list elsewhere asking what mediation/personnel issue >> reporting policies that different Foundations have (or not have). >> >> >
