Skip to content

Latest commit

 

History

History
115 lines (70 loc) · 8.54 KB

CONTRIBUTING.md

File metadata and controls

115 lines (70 loc) · 8.54 KB

Search before you ask! Someone else has probably asked your question already. Here is a search example

Table of Contents
When you have a problem
 In general: 1 - Be nice, 2 - Be public, 3 - Be patient, 4 - Non-English is okay
 Suggestions: Check your installation, Provide full command output, Use markdown, Say thanks!, Close your issue, Bikeshedding
About Labels
Answering Issues: Use links, End with a question, Reformat issues, Apply priorities, Close issues

When you have a problem:

In general

1 - Be nice

All of the workshops and all of the discussions are done by volunteers and there is no guarantee that all questions get answered. If you only provide negative feedback and not constructive criticism your issue will probably get closed with no response.

2 - Be public

Don't email workshop authors directly, use the public discussion forum (the Issues) for all communication, that way your question and any answers you get can benefit everyone else.

3 - Be patient

It may take a day or two for people to respond here. Please don't send multiple messages in a row, it won't help your question get answered any faster.

4 - Non-English is okay!

If you can't read or write english well its better to write additionally your question in your native language. There are many people on this site and maybe people can help you in your mother-tongue.

Suggestions

Check your installation

Often the installation on windows makes problems. But also other systems can experience troubles. Please also check out the installation suggestions if you have problems.

Provide full command output

To help us debug your problem please include all output from the commands you ran, including any error messages you received.

It also helps to include your node, npm, git or other CLI command versions, which you can get by running node -v, npm -v etc.

Use markdown

Github offers a lot of support to format your issue. It makes it easier for other people to understand your problem.

Say thanks!

The person that helped you did it out of the kindness of her/his heart. Tell your appreciation by saying thanks 😄 !

Close your issue

If you don't close your issue another person will have to clean it up later.

Bikeshedding

Its okay to bikeshed issues but if you do it would be nice to update it every 14days or so to let people know you still have interest.

About Labels

Only owners can add labels to the dicussions issues. We added a lot of labels that makes it easier for contributors to understand the content of an issue. Here is their intended meaning:

Label Meaning
bikeshedding This issue is kept open in case someone wants to jump in. It should be updated every now and then (~14days).
contains hints for improvements This contains hints on how a workshopper/tutorial/website etc. can be improved. The issue should be closed when the improvement was added to the content in question as a PR or issue.
general node.js This is a question not specific to a content in this repository but rather to node.js in general.
installation This is an issue with the installation of node or a workshopper.
mac This is an issue specific to computers with Mac OS X.
needs some love This issue is not simple to answer or process. More effort than average needs to be put into this issue and it needs the love and support of the greater community.
probably self resolved This label is for the case that the person that asked the question has not answered for a longer period of time (~14 days). It should be used by the person who closes an inactive thread to show that she/he thinks that the user probably resolved this issue himself. Usually only closed issues should have this label.
seems resolved This label is to indicate that the issue seems resolved but the user forgot to close the issue. Usually only closed issues should have this label.
question This issue contains a question that is not a problem.
waiting for feedback This label is to remember that the issue has been answered but is waiting on additional information or more response.

If you want to add labels to issues, don't be afraid to ask for permissions. Its a github restriction that only owners can add labels.

If you have an issue that doesn't match a label, feel free to add a label and describe it here.

Answering Issues

Owner or not: If you have an answer to a question please don't hesitate to add a comment. There are people who answer issues regularily but those are also volunteers and also only try to do their best.

It is not necessary to follow this but there are some things that we found useful to keep in mind:

Use links

Many questions are similar. If you can link to other issues or web content that makes your life easier. Keep in mind that the other person still needs an explanation why you give this link.

End with a question

If you add a question at the end it puts the ball back to the inital questionee and indicates that you think that this comment should fix the issue of the person. i.e.:

  • Could you try that?
  • Does that help you?
  • Does that solve your problem?
  • Do you need more information?

Reformat issues

Owners can edit issues. It is often not a good idea to change the issues but adding Syntax Highlighting often helps readability and increases the chances of a good response so that we consider that a good exception.

Apply priorities

In case you feel confident to answer multiple issues it might be a good idea to follow priorities. An example for priorities might be:

  1. Issues with no labels: Add labels
  2. Issues with no comments: Think of an answer
  3. Issues that are least recently updated: Add the waiting-for-response label in case its not given and ask a question in case none has been asked.
  4. Issues that need-some-love: Try to think how to resolve those because they need your love!

Close issues

If you see an old issue lurking around feel free to apply labels as mentioned above and close the issue if reasonable!