Re:How to avoid humiliating newcomers: A guide for advanced ...
by commandlinefan on Friday March 16, 2018 @03:27PM
(#16603339)
Well, on the flip side - I've had similar experiences to cosban's, and it usually goes like this: I'm neck-deep in a complicated scenario, and I'm stuck and can't figure out what to do next. I can ask for help, but it will take pages of explanation just to describe how I got where I am. Recognizing that everybody's (myself included) attention span only goes so far, I try to describe just the problem I've run into in as few words as possible without going through the whole epic story. Then somebody comes along and says "what you're doing doesn't make any sense, you shouldn't be doing that"...
Re:How to avoid humiliating newcomers: A guide for advanced ...
by watwut on Friday March 16, 2018 @04:24PM
(#16603758)
Many questions come from beginners - and they are often trying to do the wrong thing. The developer who is answering you don't know who you are nor what you tried before, it makes sense for them to eliminate most common scenarios first before advising on something complicated.
It is not necessary personal nor lack of good intention, it is that experience with answering questions teaches you that it is overall most effective to check whether the problem can be solved differently as it often can be done.
There should be an explicit three-way breakdown for this:
1. You're having trouble because of a bug, either yours or ours. If it's yours, the helpful thing is to help you fix it. If it's ours, obviously all projects should accept bug reports gracefully and work on them in some kind of reasonable fashion.
2. You've hit a deliberate design limitation, which isn't a bug as far as we're concerned, but we're willing to acknowledge it's annoying. This might turn into a feature request.
3. This is out-of-scope for our project. You picked the wrong tool. Getting us to change scope probably isn't going to be done using a bug report. That should be stated politely and without denigrating you or your problem.
What should not happen is what you describe: Developers fitting problems into a Procrustean bed and cutting off the bits which don't fit the pre-designed mold, and then claiming that this cut-down problem is all anyone would ever need to solve. It's sometimes inevitable that you have to simplify the solution by simplifying the problem, but never pretend that a solution thus simplified is complete.