FIG CoC - take 2

[Larry Garfield]

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

[Lukas Kahwe Smith]

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

--
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+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/a6954973-11df-49cf-ad92-5d9c8fb195d1%40www.fastmail.com.

--

regards,

Lukas

[Matthew Weier O'Phinney]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAEFKHaGofSXVPrMN1djpzLuD4tbaaZCXJAgi5f1VKN8ZEhh6Ag%40mail.gmail.com.

--

Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

he/him

[Michelle Sanver]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myXExY5KQvRS6ktwdmbWGCZ4WhiGBCV30Y--UYM%3Dzc6E3w%40mail.gmail.com.

[Larry Garfield]

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

[Lukas Kahwe Smith]

On Sun, Aug 9, 2020 at 12:14 AM Larry Garfield <la...@garfieldtech.com> wrote:

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?

yes but the issue is that the manifesto does not sufficiently define what problematic behavior is. also the covenant v2 also tries to give an indication of the consequence ladder which helps to increase clarity.

 

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.

if that remains the case, then I guess the indeed secretaries are automatically also tasked with handling reports.

now in case of the most extreme offenses resulting in a need to ban someone, which would also require an expulsion if that person holds a formal position, there would need to be some sort of process by which voters get informed but in a manner that respects the privacy of the accuser and accused.

 

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.)

I do not intend to speak here on behalf of Michelle but I have some thoughts on this ..

while I think the cost of a CoC training is not prohibitively high and anyone doing such a training will benefit in many ways, I do understand this line of reasoning. which is why I would like to see this professionalized and offered as a service to the PHP community. but that is likely beyond the scope of this first step.

 

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.

agreed. at most some general indication to remind them of the responsibility to maintain the privacy of the accuser and accused as much as possible while ensuring the stated goals for safety in the community to be the highest priority.

--

regards,

Lukas