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

Code of conduct #819

Closed
lunaryorn opened this Issue Dec 11, 2015 · 15 comments

Comments

@lunaryorn
Contributor

lunaryorn commented Dec 11, 2015

Before we open and announce a Gitter channel for Flycheck (see #796), I'd like to setup a code of conduct for Flycheck that defines what we consider acceptable and desired behaviour within our community and within our communication channels.

Since I do not have a lot of experience with this topic, and since I'd not like to re-invent the wheel, I think it's best to copy from a successful community. Specifically, I've read Rust's code of conduct. I like it because it's quite elaborate on acceptable communication; specifically it forbids insults and setups a reasonable policy on banning users.

We didn't have any incidents yet, but better safe than sorry :)

@lunaryorn

This comment has been minimized.

Contributor

lunaryorn commented Dec 11, 2015

Inviting @jwiegley, @flycheck/leads, @flycheck/maintainers and @flycheck/extension-developers. If you'd like to invite anyone else for their feedback, please feel free to do so ☺️

@cpitclaudel

This comment has been minimized.

Member

cpitclaudel commented Dec 11, 2015

Great idea. And Rust's code of conduct is a good one, I think. I also like the ones of Julia and FreeBSD

@cpitclaudel

This comment has been minimized.

Member

cpitclaudel commented Dec 11, 2015

@purcell

This comment has been minimized.

Contributor

purcell commented Dec 11, 2015

Another option: http://contributor-covenant.org/

Yep, for personal conduct this one looks good. I like the idea of a "standard" agreement in this space.

@lunaryorn

This comment has been minimized.

Contributor

lunaryorn commented Dec 12, 2015

I don't know, I find the Contributor Convenant, well, very brief and vague, and there's a couple of things I miss:

  1. It's purely negative, describing unacceptable behaviour, but gives no idea of acceptable and excellent behaviour.
  2. It's pretty hazy on the consequences of unacceptable behaviour.
  3. It provides little help and guidelines for moderation.
  4. It provides no path of appeal against moderator decisions.
  5. It provides no help for resolving conflicts without moderation.
  6. It focuses only on harassment, but my personal idea of undesired behaviour goes beyond that; specifically I'd like to include cursing and use of foul language, caustic comments or snide remarks, off-topic ranting and unstructured critique in our definition of undesirable behaviour.
@lunaryorn

This comment has been minimized.

Contributor

lunaryorn commented Dec 12, 2015

By contrast, the Rust CoC goes to great length to address (most of these) things:

  1. "Please be kind and courteous." […] "Don't just aim to be technically unimpeachable, try to be your best self."—It also tells users how they should be, not just what's unacceptable.
  2. It has moderation policies that help users to understand the consequences of unacceptable behaviour and moderators to correctly enforce the CoC.
  3. It has some kind of appeal process, by taking up issues with moderators privately and by a potential un-banning after a genuine apology.
  4. It describes a strategy to avoid conflict, namely to cease doing whatever other people dislike and apologize no matter whether you believe it's justified or not.
  5. It aims to reduce unstructured critique, prohibits trolling, flaming and baiting, and goes against rude behaviour.

For the same reasons, I also like the FreeBSD CoC, though it lacks moderation guidelines. Specifically, I really like the "don't try to take offense" rules, like in the Rust CoC.

I think this is a really great strategy to avoid many personal conflicts about technical issues before they even arise, and I think that's a very important thing to keep discussions focused and on-topic.

This was referenced Dec 12, 2015

@mgudemann

This comment has been minimized.

Contributor

mgudemann commented Dec 12, 2015

+1 for the positive aspects, i.e., primarily setting positive goals instead of only describing unacceptable behavior. The FreeBSD variant looks quite good to me, while the Rust variant would require explicit moderators, if I understood correctly.

I also suggest in addition s.th. in the line of:

  • Please understand that people develop this in their free time and in general have many other commitments.

With the main goal to encourage people to read documentation and to provide useful reports in case of problems, and also to accept inaction / decline of s.th. they suggested if it mainly means work for maintainers.

@cpitclaudel

This comment has been minimized.

Member

cpitclaudel commented Dec 12, 2015

@lunaryorn These are very good points. I like the Rust and FreeBSD ones, so feel free to pick!

@lunaryorn

This comment has been minimized.

Contributor

lunaryorn commented Dec 15, 2015

@mgudemann While I understand your point and see your concern, I think that this statement mirrors a general fact in open source projects, and is as such beyond the scope of our code of conduct. Furthermore I think that statements of this kind can easily become intimidating, which sends a message to new contributor that I'd rather not like to send.

@mgudemann

This comment has been minimized.

Contributor

mgudemann commented Dec 16, 2015

@lunaryorn ok, no problem.

I just had in mind projects where people demanded features or asked questions without putting any effort in it themselves, this may get tiring with time. On the other hand, this concerned mainly mailing lists. Currently, this seems much more rare with github issues, let's see how the gitter chat works out.

@lunaryorn

This comment has been minimized.

Contributor

lunaryorn commented Dec 16, 2015

@mgudemann I doubt that a code of conduct would successfully mitigate this behaviour. A user who does not research for their own problem would usually not bother to read a code of conduct either, and just ask. In this case we'll just ask them politely to demonstrate research effort, or show what they have done, and call it a day.

Besides, I do not think that stupid questions are bad. On the contrary, I like to see them as disguised bug reports about our documentation. In my experience few users have bad intentions in and by themselves.

More often than not a stupid question does not reveal laziness or a lack of effort but a shortcoming in the accessibility, structure and contents of the documentation and tutorials. Consequently, I believe that the "vile lazy user asking stupid questions" is mostly a stereotype invented by developers and support people, because casting doubt on the user's intentions is always easier than challenging and improving your own documentation 😏


With regards to feature requests, I think it's a common understanding in open source that accepting and prioritising those is the maintainer's prerogative. I don't think that the code of conduct needs to repeat this.

Finally, I'd not like to impede, let alone inhibit, discussions about features. Anyone is free to disagree with our decisions, and to express their disagreement in comments, as long as they do that respectfully and constructively, i.e. within the rules set by our code of conduct.


Simply put, the purpose of our code of conduct is to give rules for how to ask questions and lead discussions, but not to define "allowed" and "disallowed" discussions. ☺️

@cpitclaudel

This comment has been minimized.

Member

cpitclaudel commented Dec 16, 2015

@mgudemann Indeed, this kind of problem seems to be a lot more uncommon on Github than it is or was on other platforms, such as Sourceforge. It may be because the typical user on Github has a lot more software development experience, but I've found bug reports and general discussions here to be generally a lot better.

@mgudemann

This comment has been minimized.

Contributor

mgudemann commented Dec 16, 2015

@lunaryorn

[...] casting doubt on the user's intentions is always easier than challenging and improving your own documentation 😏

I fully agree with you, and I think that having a Code of Conduct to encourage respectful and constructive discussion is a very good idea.

@lunaryorn lunaryorn self-assigned this Dec 19, 2015

@lunaryorn

This comment has been minimized.

Contributor

lunaryorn commented Dec 19, 2015

I'll go with a modified variant for the Rust CoC then, and prepare a pull request.

lunaryorn added a commit that referenced this issue Dec 29, 2015

lunaryorn added a commit that referenced this issue Dec 29, 2015

@lunaryorn lunaryorn closed this in b3fc4f3 Jan 2, 2016

@lunaryorn lunaryorn removed the in progress label Jan 2, 2016

@lunaryorn

This comment has been minimized.

Contributor

lunaryorn commented Jan 2, 2016

Now it's there: https://github.com/flycheck/flycheck/blob/master/CONDUCT.md

Thank you for all your feedback and for your valuable input!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment