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 -- 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/CAEFKHaEsmakZenLTd7GT3KyUtcnPyYGwRs59PVwxvSAR6Gg_6A%40mail.gmail.com.
