Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review Code of Conduct #59

Open
saljuama opened this issue May 18, 2021 · 6 comments
Open

Review Code of Conduct #59

saljuama opened this issue May 18, 2021 · 6 comments
Assignees
Labels
To discuss The topic we'll be discussing at the next codebar chapter organiser meeting

Comments

@saljuama
Copy link
Member

Given recent events where we had to deal with code of conduct breaches, while dealing with the person, the current state of the CoC made it a bit difficult to communicate with the person.

In general the current CoC focus on what NOT to do, and the wording is around strong cases.

What I would propose is to be also explicit on what is the desirable behaviour within Codebar in a more explicit manner.

Here is a very extensive example (https://www.scala-lang.org/conduct/), we don't need something this extense, it is just to provide an example on how to express this positive reinforcement.

@KimberleyCook KimberleyCook added the To discuss The topic we'll be discussing at the next codebar chapter organiser meeting label May 19, 2021
@brunogirin
Copy link

I also like the Contributor Covenant one as it has enforcement guidelines too: https://www.contributor-covenant.org/version/2/0/code_of_conduct/

@KimberleyCook
Copy link
Contributor

  • Update Code of Conduct - adding in what behaviour is expected, direct examples of unacceptable behaviour, direct contacts details of Me, Kriszta and Despo, and link to new "what happens if you breach the CoC doc" somewhere there.

  • Potentially get people to agree when signing it (get Despo to do her magic).

@KimberleyCook KimberleyCook self-assigned this May 27, 2021
@brunogirin
Copy link

brunogirin commented Jun 3, 2021

Should it always be the same list of direct contacts or could you have a first level of contacts when an issue occurs during an event, e.g. the event organisers?

Use cases:

  • Generic: Kim, Kriszta, Despo
  • Event: 1st level, event organisers; 2nd level, Kim, Kriszta, Despo

The benefit of involving the event organisers is that they may be able to address the problem immediately but have a fallback if they can't. However, that may complicate the wording a bit.

@KimberleyCook
Copy link
Contributor

@brunogirin if all organisers are happy with that, I'm happy to have it that way :)

@KimberleyCook
Copy link
Contributor

@KimberleyCook
Copy link
Contributor

PR adding in the new breach CoC procedure codebar/planner#1582

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
To discuss The topic we'll be discussing at the next codebar chapter organiser meeting
Projects
None yet
Development

No branches or pull requests

3 participants