Getting back to this... It looks like there's a couple of different threads here, which I will try to separate:
1) Code Manifesto vs Contributor Covenant. I really wish we wouldn't get hung up and side tracked on this, honestly. That said, I read over the CC v2 link that Lukas posted and it looks like v2 addresses a lot of my concerns with v1, especially the negative/punitive structure of it. That's very good to see. I still favor the Manifesto model, and even CC v2 would need some tweaking for FIG (as below) but I am not as firmly opposed to CC v2 as I was to v1. 2) Regarding enforcement, I have to admit I'm confused. The Manifesto doesn't include an enforcement model built in, that's true. But the PR does. It very clearly lays out that violation of the CoC is grounds for removal, and in what situations and by whom such removal happens. Does anyone have input on that specifically? Of note, for official positions there is an existing removal process already in place (there's votes for it), which I believe is appropriate to retain. While for most people having the Secretaries (what the CC v2 calls Community Leaders) temp ban or perma-ban someone for mouthing off too far is fine, for elected positions I do believe a bit more formality is appropriate and warranted. I was also trying to keep the procedural changes to a minimum, when we already have procedures in place. 3) Michelle, are you suggesting we should have a separate CoC/CARE/Community Working Group/Thing group distinct from the Secretaries, or just giving that as background? While I agree training in CoC handling can be useful, in practice FIG is small enough and low-bandwidth enough that I'm not sure the ROI of formalizing it is worth it at this point. (If we got to that point, I'd consider that a "good problem to have" but right now it's not a problem I think we have.) 4) Specific tooling to assist in the process I don't believe belongs in the bylaws. Should the Secretaries/whoever find it useful, sure, that's fine by me, but at least as far as the bylaws are concerned "these are the people, this is their email" seems sufficient. -- Larry Garfield la...@garfieldtech.com On Tue, Jul 28, 2020, at 10:23 AM, Michelle Sanver wrote: > > To chime in quickly as someone from the Symfony CARE team, who now has > quite some time of direct experience, and the CoC training. The > training was very valuable, even for someone who thought they were > experienced like me I learnt a lot. Highly recommend it. > > Without an enforcement concept in place a code of conduct serves more > as a guideline how to behave, than a tool to make people in our > community feel safe and cared for. I think it’s important to have that > tool together with the process and the people in place. I think we > dealt with it in a good way in the Symfony community, and we can serve > as an example - But I may be biased. > > With gratitude, > Michelle Sanver > On 27 Jul 2020, 22:38 +0200, Matthew Weier O'Phinney > <mweierophin...@gmail.com>, wrote: > > I agree with Lukas' points. > > > > While we adopted the Code Manifesto for ZF some years back, the problem we > > ran into was a lack of reporting guidelines; it's essentially an optimistic > > "be nice to each other and consider the impact your words/actions have on > > others" directive, with no recourse when somebody violates it. While we > > would occasionally take action, it was never _consistent_ or _transparent_, > > which is what a good CoC needs. > > > > (Now that we're under the Linux Foundation, we use their guidelines, which > > are based on contributor covenant, IIRC.) > > > > Is the tooling available for us to review and comment on, or even > > contribute to, Lukas? That in itself would be a huge contribution from FIG. > > > > On Tue, Jul 21, 2020 at 4:42 AM Lukas Kahwe Smith <sm...@pooteeweet.org> > > wrote: > >> Aloha, > >> > >> thank you for bringing this up again. > >> > >> there were already quite a few comments on the PR at the time, which > >> interested people should have a look at. > >> > >> I also share the concern that this CoC lacks explicitness which is why I > >> also favor a covenant of code based CoC. this is what we created for > >> Symfony. > >> https://symfony.com/doc/current/contributing/code_of_conduct/code_of_conduct.html > >> > >> Since then version 2.0 was released, which I have not studied in detail > >> but afaik it now contains enforcement guidelines > >> https://www.contributor-covenant.org/version/2/0/code_of_conduct/ > >> > >> for Symfony we have created our own (heavily inspired from Sunshine PHP, > >> who in turn were inspired by others): > >> https://symfony.com/doc/current/contributing/code_of_conduct/reporting_guidelines.html > >> > >> Of course it is important that people receiving reports know what they are > >> doing. For Symfony we got a group of people trained by Sage Sharpe: > >> https://symfony.com/doc/current/contributing/code_of_conduct/care_team.html > >> https://otter.technology/code-of-conduct-training/ > >> > >> Semi related to this there is an initiative to create a tool for CoC > >> reporting. The key benefit I see is: > >> 1) proper handling of records > >> 2) ability for anonymous reporting > >> 3) ability for report handlers to be excluded or to recuse > >> 4) ability to collect statistics that could help identify cross community > >> "grey" behavior > >> > >> Note the tool is not yet "production" available. Mostly because there are > >> 3rd party evaluations missing. > >> But this could be an amazing service for the entire PHP community. > >> > >> So to me the key things I would like to have changed: > >> 1) more explicit > >> 2) reporting guidelines > >> 3) trained team to handle reports > >> > >> However I do think this is a step forward, but I feel quite strongly that > >> without 2)/3) we might just offer a solution that will fail affected > >> people when push comes to shove. > >> > >> regards, > >> Lukas > >> > >> > >> > >> On Mon, Jul 20, 2020 at 2:50 AM Larry Garfield <la...@garfieldtech.com> > >> wrote: > >>> Hi folks. > >>> > >>> Last year I proposed a CoC for FIG, based on the Code Manifesto by Graham > >>> Daniels. It was subsequently edited a bit by former FIG Secretary > >>> Margaret Staples. I left it lie for a bit in the hopes that Margaret's > >>> changes would be merged back into the Code Manifesto proper, but that > >>> never happened and then I got distracted by other things and then the > >>> world turned upside down and... yeah. > >>> > >>> So, I'm finally back with take 2, which is really just continuing where > >>> the previous attempt left off. Specifically, this PR: > >>> > >>> https://github.com/php-fig/fig-standards/pull/1143 > >>> > >>> The only change I am still debating myself is whether to include > >>> "lifestyle choice" as one of the forms of discrimination that we're not > >>> on board with. It is a distinction that is important to me (as many > >>> know), but I know that others fear it is too easy to hide jerkish > >>> behavior behind. That said, I'm certain a dedicated jerk could hide > >>> behind absolutely any label if they put their mind to it. Hence my > >>> hesitation. > >>> > >>> Since it's been so long I'll consider this a new discussion period of > >>> minimum 2 weeks, with the intent to bring it to a vote shortly thereafter. > >>> > >>> -- > >>> Larry Garfield > >>> la...@garfieldtech.com -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/71f15901-9f79-4aeb-a7c6-3c32d4ac5dba%40www.fastmail.com.
