# GitHub Etiquette
borrowed from [Open source etiquette](https://github.com/kossnocorp/opensource.how)

## Don't be mean!

Be nice!

## Don't be bossy!

  It takes just a few seconds to type "Any updates on this?" but it takes much
  more time and energy to write a report back to you. First of all, you're not
  maintainers' boss, and they owe you nothing, not to mention a report.

  These minutes could have been spent on something meaningful, so you not only
  steal time from the maintainer, but also the whole community.

  Don't write like a boss: "Why this isn't merged?" "What's the ETA?" "It blocks
  us!" "What are the blockers?".

## Don't demand!

  Never demand anything from maintainers. Always keep in mind that maintainers'
  work is an act of goodwill — even labor backed by the community rarely pays
  more than minimum wage, so communicate accordingly.

  If you need a piece of information or help, say it politely. If you want to
  have something done, never push.

  First of all, you could have different priorities. You and your colleagues
  might be aligned on the same goal, but maintainers can have a different focus.
  Secondly, you might have a different perspective on the problem. Be ready to
  accept a rejection of your proposal, feature, or bug report. Yes, sometimes,
  bugs are features!

## Don't be noisy!

  Comments like "I also have this error" and "+1" are never helpful. It's
  especially tempting to type such comment when it's a critical issue, but that
  adds additional pressure and distraction.

  If you want the get the attention of the maintainer, at least contribute
  something. If the issue lacks stack trace or reproductions steps, add it.
  Don't feel capable of opening a PR? Create a minimal repo with the demo of the
  error.

## Don't rush!

  Take your time before reporting a bug or asking a question. First, make sure
  you're not missing anything. Read the docs, Google the problem, search the
  issues, double-check, and only then reach for help.

  When you do reach for help, make sure that you provide as much information as
  possible. Proactively present library versions, code example, reproduction
  steps, etc. Describe the problem in detail. Don't wait for the maintainers to
  ask you for that. Provide or at least offer to provide a minimal reproducible
  example. This way, you'll minimize the effort that they have to put to help
  you, which would maximize your chances to prompt response.

  It's easy for you to assume that all they need is a short description of the
  problem as the maintainers know their thing the best and provide additional
  information only when they ask you. But in that's just a time steal and the
  best way to get rightfully ignored.

## Don't be emotional!

  When the deadline is approaching and you still have a lot to do, a bug or
  unexpected behavior in the code you don't control is annoyance at least. Never
  show it!

  The maintainer has a different perspective and might not be aware of the
  problem even if you feel like everything is broken. If you want to get help,
  then be calm, objective, and patient.

## Don't patronize!

  Never assume that the maintainer is less experienced or knowledgeable or
  straight stupid. That better approach, tool, or decision that you have in mind
  might have been considered or even planned. They have full context and had
  much more time than you to think everything through, so more likely, it's you
  who's confused.

  It's reasonable to think that the maintainer is an expert in the subject, and
  you're not. Even if you find an objectively low-quality code, don't assume the
  authors' experience or skills.

  If you disagree with the direction, instead of arguing, it's better to
  consider an alternative. Some prefer functional programming, some
  object-oriented code, but that doesn't mean that latter or former are wrong.
  The maintainer should be able to decide what trade-off to choose regardless of
  your needs or views.

## Don't forget to say thanks!

  Simple words of gratitude and praises are often the sole motivator that makes
  open-source authors keep going, so don't be shy and say it!

  Do you want to see a pull-request merged, much-needed feature implemented and
  long-awaiter release shipped? Instead of reminding how much work is on their
  plate by asking "any news" or showing dissatisfaction (which only kills the
  motivation), say how their work is essential. Tell how much you value them.
  Tweet kind words about them and their project. Sometimes that's the best you
  can do.

## Don't cause drama!

  Never post comments that might cause a drama or emotionally hurt maintainers.

  You might be upset about maintainers intrusively asking for donations. You
  might be frustrated by the lack of attention to your issue. You might be
  dissatisfied with the quality of the project. You might know the better
  alternative. You might think that's enough for you to post a comment demanding
  to remove annoying ads or announce that you're moving to another solution. No,
  it's not.

  For you, that would be a simple message, but on another end, it might ruin the
  day or strip out the motivation to continue. That's not the right way to treat
  people that decided to give something for you for free, even if it's not good
  enough.

## Don't surprise!

  If you plan to contribute great work to a project, communicate it first. Your
  vision might differ from the maintainers' one, or it could collide with their
  plans or ongoing work. The worst way you could help them is to create more
  work.

  If you get rejected, be understanding and not try to cause the feeling of
  guilt. It's already hard for maintainers to say no, so don't make it harder.
  Feel free to clarify your intention if you think they misunderstood you but
  never start an argument.
