[doc] How To Request Support document stab
Author: stas00
Pull request: yes

As discussed it'd be great to have a clear document with guidelines at how to create great Issues that are easy to understand, reproduce and resolve. I wrote this stab of a document to get things started.

Please feel free to edit it further to your satisfaction. I'm not attached to any parts it, just brain dumping what was coming based on my experience. So feel free to add remove, reformat, etc. Best commit your edits directly into this branch or second best via suggestions. I don't need to be the middleman.

Please tag others that you think may want to contribute to this document.

If this is successful, perhaps a similar document will be needed for PRs - or perhaps down the road it will be a single document as there is a lot of overlap between writing a good Issue and a good PR. But let's start simple.

@sgugger, @patrickvonplaten, @LysandreJik 

Comments:
I really like the idea of adding such a document. Two general things:

1) I think we should make this document a bit more positive and not a "mandatory read" before posting an issue. IMO, in general we are (or should be) happy about all issues. Even if the issue is very badly formulated, it gives us a good signal on how the users work with the library and which features are more and which are less used.

2) I'd make a clearer distinction with what should be in the forum and what should be an issue. I've probably already answered ~30 times on issues that the user should please redirect the question to the forum. I'd like to make a clearer distinction here:

The issues should ideally only be used for bug reports.

**_Forum:_** All "please explain" questions or objectively very user-specific feature requests should land in the forum. IMO those should never land in the issues. What I mean by that are *e.g.* the following kinds of issues:

i. "I would like to use a BertModel within a RL-Agent for a customer support service. How can I use a `BertForMaskedLM` in my `ChatBotModel`?"

ii. "Could you please explain why T5 has no positional embedding matrix under `T5Model`?"

iii. "How should I set my generation parameters for translation?"

iiii. "How to train T5 on De->En translation?" 

=> all these kinds of questions do not belong to the issues IMO. None of those issues hint at a bug in Transformers and have definitely a better place in the forum IMO. But, again, we **do** want people to ask exactly these questions and I'm more than happy to answer all of them (maybe i. a bit less). Not sure what @thomwolf @LysandreJik @sgugger think here.

**_Issues:_** Everything which hints at a bug should be opened as an issue in Transformers. Here again, I'd like to encourage people to open issues as I'm much happier with users posting an objectively badly written issue than with users discovering an issue, but being afraid to post it in Transformers. Having said this, I really like the points you've written down so far @stas00! One thing, I like to add (as one of the first points) is that users should google (or whatever SE) their issue before opening the exact same one (yes using a SE with "your issue here" + "transformers" + "huggingface" often gives better results than searching on github itself). I often just link a new issue to an already answered one (which is also not that bad since it shows us again which parts of the transformer are heavily used). And I think in some cases it is fine if the user posts a link to a colab if it's bug absolutely requires a big data set.

In general, I think such a document can save us a lot of time because we can just link to it on issues that are badly written and usually are as a consequence just ignored by us. Think the author of a "badly" written issue can then better understand why we sometimes stop answering.


Great suggestions, @patrickvonplaten - Thank you - I hope I integrated them well.

I think at this point we are in the gathering stage - so bring on the ideas and points you feel are important.

When this stage is done we will do a final edit so that the document feels most welcoming to the users.

All comments/suggestions you have kindly offered so far have been addressed. A vous!

> After applying Patrick's suggestion, I think this document is in excellent shape. One nit I would have is that it's written in perfect English. We have a lot of users that are not native speakers, and possibly won't understand some parts of it. Then again, I don't think we should reduce the quality of this document, but let's think about what we can do in general to be friendly to non-English speaking users/contributors.

Oh, thank you for the complement as I'm one very non-native English speaker ;) But I totally hear what you mean.

Perhaps the simplest thing to do is to add a note that if someone struggles with understanding anything in the document, they can ask us to make it more easy to understand? That way it doesn't have to be imperfectly perfect from the get-going.

Merging, thanks a lot @stas00!

Copied this into [this forum post](https://discuss.huggingface.co/t/how-to-request-support/3128) and added a link to it in the document in [this commit](https://github.com/huggingface/transformers/commit/6009668c631aa5773c66aa30c6bfd9c191e2a6be).