I was assuming that the suggestion was the customization of the discobot welcome message to include this post.
Proposal for an additional point on the list:
You are more likely to receive meaningful help if you avoid most non-standard characters, i.e. characters that are not present on almost all international keyboard layouts. This means de facto sticking to ASCII characters on US layout keyboards, plus some very well-established special cases like
⊻ (infix xor) or
∈ (alias for
in). It is rude to expect the international audience on discourse to figure out how to input your native characterset or your not-universally-used symbols (e.g. unicode subscript or superscript, greek characters, accents).
I don’t necessarily disagree, but want to keep the list short and IMO we don’t see a lot of obfuscated unicode from newbies that often.
How about adding this?
Include full stacktrace and error messages. They often contain valuable information even if they may seem cryptic to you. Please quote the stacktrace as well (see point 1).
Great idea, but for some reason I cannot edit the post. I think it Discourse does not allow editing old posts. @vchuravy, can you somehow allow me to do this?
I turned it into a wiki so you (and other folks) should be able to edit it.
This is a great piece of advice for new comers. I see frequent mention of this in responses. I would suggest that this appears as a pinned message at the top this site.
I wonder… is is possible to make the original post appear on the “New topic” popup?
I like your list because it’s positive actions, i.e. things you should do.
However, the recent increase in people posting for help and putting in screenshots might make it worthy to add an explicit,
Please don’t use screen captures
edit: oh good grief. it’s already there. thx @oxinabox
It is already there, under point 1, in bold
Regarding simplifying the problem — this is invaluable when done with skill, but I find that many people oversimplify and their toy example looses the essence of the original problem.
Perhaps we could suggest that, when simplifying, people include some minimal context about their original problem. Some examples:
- The name (and link to) the original julia code from which the MWE was derived
- The name of the original library and function they were trying to ccall
- The domain-specific name of the technique they’re trying to implement
Those kind of things; a sentence or two giving enough detail that people who are interested in a deep dive can help them out without repeatedly having to ask for more detail.
I think that requiring an MWE should add a bound to oversimplification, and we can always ask for extra details.
Abstracting out the essence of a problem is an art in itself, which is hard to convey in guidelines like this.
EDIT: added specific instructions to obtain version information with
An MWE is fine for error messages and such where there’s a clear criterion on the “working” in MWE.
But I guess I’m thinking about more general open ended “how do I…” questions where the user hasn’t been able to construct something which is actually working.
I think you raise a very valid point, it’s just that I don’t have a good solution for it within the scope that I intended for this guide.
Specifically, I meant this to be a collection of “obvious” suggestions: all of them are low-hanging fruits, and are meant to be easy to address with a specific action.
I am hesitant to extend list with suggestions that require a longer explanation, because I am concerned that the longer we make it, the less of it will be read.
Perhaps consider making a blog post with examples, then I would be happy to link it.
Btw, it was recently brought up on Slack in #community that some of the veterans who provide help to newcomers here on Discourse could also use a little more sensitivity and be a little more welcoming. I don’t spend a lot of time on Discourse, but there is some concern about the tone and friendliness here. Just FYI.
Possibly — but please kindly discuss this in another topic.