Asking For Technical Help
Thurs 10th Nov 16
I subscribe to quite a few projects on GitHub, am on a number of public mailing list and watch a handful of forums and all of these regularly get requests for technical help. These requests vary in quality so I thought I'd write this post to say what I like to see in a request and try to explain why.
Most of this is from the perspective of me answering questions for free in my spare time where I could be doing other fun and interesting things. I am happy to do this as plenty of other people do it in return for me and if it is for a tool I've written I want people using it. Having said that, questions asked in the right way make me much more inclined to put effort in when answering rather than giving a one liner and then going off to play with the kids.
Research
Before asking any question, do your homework. Check the README file, go through the tool's project pages and do some Googling, bugs are rarely unique to one person and so a bit of research can often give you the answer without having to ask in the first place.
Asking The Question
If you have to ask, the worst style of request, unfortunately seen fairly regularly, is:
The application doesn't work, please help me.
That is it, no more information, nothing. This type of request is pretty much useless as there is nothing for the people helping to go on, the problem could be a anything from the PC not being plugged in to a bug in the app.
We then go up from there to something like this:
The application doesn't work, I get this error ..., please help me.
This at least gives some context but often without knowing how the app was ran, the environment it was ran in and other useful bits of information, it is still very hard to diagnose the problem. It can be really frustrating to spend ages offering advice for what is assumed to be a Linux environment but which turns out to be Windows or to find out that the version of Python being used went out of support 4 years ago.
Skip ahead a few requests and we finally get something like this:
I'm running version X of the app on Debian Jessie. I'm using Python version x.x. When I run it with the following command ... I get this error ... . If I remove the X parameter then all works well. I've tried running as a normal user and as root, it doesn't make any difference.
Here we have something that is much easier to answer as the following can be picked out and worked with by the helper:
- The version of the app being ran - This stops wasted time debugging problems with older versions of the app
- The OS is given - Apps behave differently on different OSs
- The version of Python is given - Again, helps prevent wasting time by testing with different versions or debugging issues caused by out-of-date interpreters or compilers
- The command and arguments are included - This makes it possible to reproduce the exact situation that is causing the problem
- The error message - This tells the helper what went wrong and maybe where something failed
- Some indication that the person needing help has tried to find the cause of the problem
Given all this information it is much easier for the helper to understand what is going on and, if necessary, replicate the problem. The more they know about the environment where the problem occurred the less they have to either guess or go back and forth requesting more information. By including that the app worked when a parameter was changed, and that they tried it as a normal user and as root, it shows that the person has tried to help themselves and also takes some of the debugging load off the helper. Showing that the user has put in some effort already always make me feel more inclined to help. It also gives an idea of technical competence of the person which makes it easier when asking questions back. This doesn't mean that I prioritise helping people with skills, I prioritise people who show they have tried, at any level.
A lot of the bigger projects have their own guidelines for submitting bugs, for example this is what Mozilla expect. Always check for these as questions will often be ignored unless they are formatted correctly and include the necessary information.
What should not be included
The most annoying thing for me is when pages of unnecessary output are included in a report. There may be times when the full output is required but if you include anything more than about 20 lines of output you are probably including unnecessary information. Errors usually happen at the end of the output so read through and see if you can see where things go from looking right to starting to fail. If you aren't sure, or you think that all the output is required, then put it in a file and host it somewhere, Pastebin is usually a good place. The helper can then go and look at it if needed but the forum/mail isn't clogged up with 10's of lines of stuff that isn't needed.
It is also worth checking what you are posting to make sure you haven't included any personal information in what is being posted. I once tried to help someone debug a problem with DVWA, he posted the link to his public facing install as part of the bug report. He fairly quickly took it down when it was pointed out that despite having changed the admin user's password he hadn't changed any of the other passwords and that he had left his server wide open to attack.
If you post images, make sure any obfuscation can't be easily undone. There have been many instances of people using MS Paint to scribble a red line through something to obscure it but leaving enough showing that it can still be read with a little effort. If you are a pen tester and are asking about a problem you are having with a test, leaking information like this may be a breach of your NDA and could get you into trouble with the client or at least a lot of embarrassment when someone points out what you've done.
Feedback
At the end of the process, leave some feedback to say what happened. Obviously you would hope that the bug is fixed and that the feedback would be something along the lines of:
We found the problem, it was cause by ... and was fixed by doing ...
But if it isn't fixed then feedback what was tried and what state you are leaving the bug in. This gives anyone one else who finds the problem a head start and means they don't have to repeat all the things that you tried.
Say Thanks
Finally, remember your manners. Especially for free tools, the people answering your questions are usually putting in their time for free so a simple "Thanks" is often their only reward, make them feel putting in their time was worth the effort. It can be very demoralising after spending time working through a problem with someone for them to just walk away afterwards.
Conclusion
Don't be afraid to ask for help, just make sure you do it as well as you can. There will always be people out there who will respond negatively no matter how well a question is asked, but a well asked question is more likely to get the good guys on your side and involved rather than them just ignoring the question because they have better things to do.
