Looking over both the manifesto and the covenant, I didn't really notice anything that would conflict between the two, if we wanted to simply include *both*... doing so would just be presenting an intersection of their requirements. Is that too much verbiage overall? Maybe just link to both, since they are standalone entities (that seem to be versioned, or at least versionable)? Stating that we want to abide by both, then delineating how those in FIG positions can act to enforce, ... maybe that would cover the concerns mentioned? CRB *about.me/ashnazg <http://about.me/ashnazg>*
On Thu, Jan 24, 2019 at 7:54 AM Larry Garfield <la...@garfieldtech.com> wrote: > On Wed, Jan 23, 2019, at 1:58 PM, Lukas Kahwe Smith wrote: > > > > On Wed, 23 Jan 2019 at 20:42, Matthew Weier O'Phinney > > <mweierophin...@gmail.com> wrote: > > > > > > > > > On Wed, Jan 23, 2019 at 2:49 AM Lukas Kahwe Smith < > sm...@pooteeweet.org> wrote: > > >> On Wed, Jan 23, 2019 at 1:17 AM Larry Garfield < > la...@garfieldtech.com> wrote: > > >> > > > >> > Greetings, FIGians. > > >> > > > >> > This has been bounced around in back channels on and off for a > while, so I think it's finally time to make it official. I propose that we > officially adopt the Code Manifesto[1] as our official standard of behavior. > > >> > > > >> > Specifically, as follows: > > >> > > > >> > https://github.com/php-fig/fig-standards/pull/1143 > > >> > > > >> > WHY? > > >> > > > >> > First off, I want to be clear that I am NOT making this > recommendation in response to any current issue. I am not aware of any > current issue that would require invoking or even discussing invoking the > guidelines listed here. FIG has been delightfully boring in that regard for > quite some time and, "good lord willin' and the creek don't rise", it will > stay that way. > > >> > > > >> > That of course is the best time to discuss such matters, as they > can be looked at from a reasonably objective and dispassionate perspective. > The definition of expected behavior of current official FIG members is > quite vague and wishy washy (by design), and having clearer up-front > expectations is good should the need ever arise. > > >> > > > >> > WHY THE MANIFESTO? > > >> > > > >> > A number of organizations and projects have of late adopted the > "Contributor Covenant" as their code of conduct. My concern with the > Covenant is that it is a very negative document; in contrast, the Manifesto > provides guidelines of good behavior rather than an enumeration of bad > behavior. In my experience, a positive document tends to encourage the > desired behavior better than a negative one. > > >> > > >> We had a brief discussion on this point via IRC a few days ago. While > > >> such a document is a very small step forward, I personally think that > > >> the manifesto lack of naming problematic behavior is its biggest > > >> weakness, since it does very little to assure people that you are > > >> willing to name problematic behavior when it occurs, when you cannot > > >> even do so in the rules you publish. > > >> > > > > > > I tend to agree with Lukas here, and have a bit of background to share. > > > > > > A few years ago, Zend Framework adopted Code Manifesto to govern our > projects, for many of the same reasons Larry has stated: we like the > emphasis on positive guidelines of acceptable behaviour over an enumeration > of punishments for bad behaviour. > > > > > > In practice, it's been problematic, for a number of reasons. > > > > > > When unacceptable behaviour is observed, there's no clear contact to > report to. This leaves people either waiting and hoping somebody will step > in, or leaving the conversation to avoid the person. > > > > > > Additionally, when somebody does step in (generally somebody with > moderation rights in whichever community forum the interactions are > occurring on), there's then questions: > > > > > > - What behaviour was observed? How is it against the code? > > > - What direction should be provided to the user to prevent future > issues? > > > - Is banning necessary? If so, how long? Should it ever be permanent? > > > > > > Essentially, a code without an explicit process for calling out > violations and dealing with them makes addressing problems entirely > subjective and at the whim of those with moderation powers. > > > > > > In terms of reporting, reporting MUST be able to be done anonymously, > to prevent retribution by the accused against the accuser; people who abuse > the rules are simply more likely to retaliate. Without this, members of the > community have no safe way to report that prevents further abuse. > > > > > > In sum: I love the Code Manifesto as a guideline for how people > > should interact within the community. However, it's not a code of > > conduct; a code of conduct needs to outline the specific behaviours > > that will trigger actions, how to report these safely, and what actions > > may be taken. These are required to ensure a safe and fair process. > > for a reporting process we last year adopted this in the Symfony > > community > > > https://symfony.com/doc/current/contributing/code_of_conduct/reporting_guidelines.html > > > > It is partially derived from the Sunshine PHP conference process, which > > in turn derived it from others. > > > > One key aspect here is also the CARE team, which also received training > > in receiving reports. Now given the limited number of people that > > participate with FIG, compared to the rather large number in the > > Symfony community, a CARE team equivalent is probably unrealistic. That > > being said, I kind think it would be awesome of there would be such a > > “response team as a service” because the same thing applies to many > > other communities .. as just because you are small doesn’t things > > cannot happen yet when something happens its important that people know > > how to deal with it properly. > > > > regards, > > Lukas > > -- > > regards, > > Lukas > > Strictly speaking, a CoC doesn't include a process for handling issues; > that's separate from the CoC itself, although I agree it's also important > to have. So I don't think the Manifesto not having one "baked in" is a > problem, as we can easily add one to it ourselves. > > Symfony's model is similar to what I've seen elsewhere, such as Drupal. > (Which isn't surprising or bad, mind you.) I agree that FIG is likely not > large enough to have a standing and trained CARE team. In our case it > would probably fall to the Secretaries to fill that role should an issue > arise. I'm not sure if they're now sweating at the idea :-), but I don't > know where else we'd put it currently without setting up another body just > for that, which at our size seems like overkill. > > So yes, we can and should include more detail around the > reporting/handling process. On that front: > > * While there may be value to a "CARE team as a service", that is very > deliberately NOT what I am proposing here nor do I think FIG is the right > place for such a team to live. The skillset that such a team would need is > very different from what we look for in project reps, secretaries, or core > committee members. Let's stick to just FIG-handling-FIG for now and KISS. > > * I have always been very uncomfortable with anonymous reporting. I can > absolutely see the value in it, and the arguments for it are valid. > However, I am also a firm believer in someone being able to effectively > respond to claims of behaviorism against them, and depending on the > circumstance that may be impossible without knowing what exactly they are > supposed to have done wrong; and providing enough "generic" information to > allow someone to respond will frequently effectively reveal the accuser in > the first place, making the anonymity effectively moot. I'm genuinely not > sure of the best approach here, but it is more nuanced than it is often > given credit for. > > --Larry Garfield > > -- > 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 post to this group, send email to php-fig@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/fdb91f9a-48ff-43a1-9581-80fe83a07430%40www.fastmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANsgjnv%2BtYJxR15i17QMRGJT%3D%3D2QtjmeDEYO4p%2B3fbgQ5Pg-QA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
