Graham, this is exactly the linking issue which I've been trying to explain. I realize in your head what you wrote makes sense, but for the rest of us who aren't in your head it doesn't.
When reading through the initial bug report we have no way to know or understand how the information you are linking is relevant. On top of that, when you what you are linking can't be fully understood without following another link, we are sure not to understand what you are trying to explain.
There have been several issues you've brought up in the past, but I simply cant make sense of what you are trying to explain. Again, I know this all makes sense in your head, but I'm not in there with you mate. I dont know the jumps you are making between points because you're not explaining them. You usually make a comment like 'further consideration' or similar. You know how it's similar because you have already read it and come to an opinion on the material. Since we dont know what you have concluded from the attached information we can't follow your thought process.
Example: In your post here. The thread seems to be about a wifi dongle, yet you decided to attach a link to the poweroff button issue? I cannot understand how the ACPI power button issue you linked from github is relevant to a wifi dongle.
-- If it's unrelated to the wifi issue, that's the type of information that should not be linked because it will only act as a distraction.
-- If it is relevant... you haven't explained why you think it's relevant and worthy of attention while we try to resolve the dlink wifi problem you are having.
Situations like this leaves us with two problems. 1)Trying to figure out the software issue which you are reporting. 2) Trying to figure out what you are trying to explain with other things you have decided to link.
I appreciate the amount of effort you put into reporting issues and I'm certain the rest of the dev staff feel the same way. I know you want to help, and though it may not seem like it, I'm trying to help you be of more help. I have been trying to get across that if you change a few ways of reporting things, your help will be so much more meaningful and have a greater positive impact on the project and the community. I feel like you get frustrated by having to continually respond when you are not understood... so lets try to avoid that in the future. The way you wrote your post script on that linked github issue is excellent, and I'm sure had you written that the first time Joe would probably have been able to follow along a bit easier.
It's true that a lot of the times issues do overlap, in those cases... go ahead and make a second issue for the related item. It will get more attention if it's treated as its own issue, since it allows us to focus on a single issue at a time. If you want to cross link them, a simple blurb at the bottom of "this may be related to $X" would be fine, but make sure that it's not required information to be able to deal with the issue that's in the title.
Regarding the apple thing you linked.
Most of what they ask for is similar to what I've listed above in those four items. Due to the smaller nature of our project, I would say hold off on crash logs and screenshots unless we ask for them. I would say that in most situations we prefer Functional descriptions over Non-functional descriptions; to use their terminology. But I'd agree with everything in
For context... compare this excellent report you made with this one. I'm not only referring to the initial report, but once you had time to investigate and then report back.
After thinking about it a bit, I think it might be a good idea for us to write up an "Issue Reporting Best Practices" guide. I'll start working on one, and discuss it with everyone in TN when I'm back down there in a few weeks.