There is a great article written by Simon Tatham that details much of what I think are ways to write bug reports effectively. I think I can take it a step further and boil it down into a few "Do's" and "Don'ts" for the tl;dr folks. In Lubuntu we have a wiki page dedicated to bug reporting. Many other projects do as well.
Do
- Do provide as much detail as possible. Even if you think a detail is unimportant it could be valuable to whomever is helping you troubleshoot an issue. It can be difficult to find information or logs sometimes, ask for help with that if you need to.
- Do give the steps to reproduce your issue. See the first Do ☝️. Being able to reproduce the problem can help further solve your issue when you are not available. Everyone uses things differently. Knowing how you arrived at the point where you need help is important in coming to a resolution.
- Do "some" research on your own. I'm not saying RTFM but yeah... RTFM. Seriously though, if you demonstrate that you attempted to find a solution on your own it goes a lot further with those trying to help. I don't mean read the documentation cover to cover but do a quick web search and try to stick to official sources. If you have a vested interest, folks providing support will too.
Don't
- Don't give up, at least not too easily. Generally speaking if someone is trying to help you they won't give up so you shouldn't either. Obviously if resolution is dragging out it might be time to say this project or product isn't right for me or at least not right now. That being said, a couple of chat messages or a few forum exchanges isn't really sufficient to determine that most of the time.
- Don't get upset. Frustration goes two ways. If you "come in hot", expect the same in response, it is how humans work. Sometimes stuff doesn't work or it breaks, it isn't beneficial to get upset, that never makes it better. It is difficult to determine intention in written words. Avoid using demanding language.
- Don't report issues about EOL or out of support things. This especially true for issues that might be fixed in a newer or supported release. Nobody is going to take the time to fix something they have already moved past. Sometimes fixes require major changes that can't be backported or at least backported easily. It isn't efficient to spend time on that. If you find issues in something that is out of date you either need to accept it or move upward and onward. Versions go up, not down.
Finally
One final Do. Do report your issue. Sure, testing should probably pickup the issue but that isn't perfect and sometimes things slip through. Everyone uses things differently so it is entirely possible nobody has noticed it. It is difficult to fix the issues you don't know about.