I think instead of using "other members", maybe just "others" so there is no confusion over what or who a member is.
I definitely like the idea of a sticky explaining how to submit bug reports. Maybe this thread should be to allow everyone to offer input and get a final explanation set up and then create a new topic that is locked/stickied once everyone agrees that is has everything necessary and is completely clear. Just a thought.
In the end, the biggest points I'd personally like to see included in any bug report are:
* Subject should be at least somewhat descriptive of the problem to make it easier to find later. That doesn't mean to write an essay on the subject line, but put something that at least lets someone browsing the forum be able to have at least a general idea of what the post is about before opening it. This makes it much easier when trying to find a specific bug report on the forum. And don't put anything in the subject line that is not related to the bug.
* OS/mIRC versions, scripts loaded, etc. This can most easily be given using the //echo line provided in the first post here.
* Detailed description of the problem. It doesn't have to be a really large description, but should include all relevant information. What is the bug? Why do you think it's a bug? From your testing, have you found anything out about the bug such as what exactly is causing it or even what is definitely not causing it? And so on. If it's relevant, include it.
* When possible, an example input followed by what you are getting as output AND what you are expecting for the output.
* If you understand why you're getting the output, but think something needs changed because you think the output should be something else, then also include WHY you think it should be changed.
* Any example code (stripped down to only what is required to produce the bug). Stripped down means not to include anything that isn't related, or if you do include it, be very clear in the post that it's not related to the bug.
* If you feel it is useful, include an image (using the forum's image tags) showing what is going on. However, the image should never be used as a description. It should only be used as an additional example.
Most of that's already been mentioned in one way or another and the link provided by argv0 mentioned the information as well. I just wanted to provide what I think are the most important things in a bug report.
As to a final version to sticky, I think we want to try to have it as short as possible while still being clear and including everything we want included. People ignore anything that's too long (like some of my posts
). Also, I think we should try to make it sound a little more "friendly". Just like with being too long, if there are a lot of DO NOT's in bold, people are less likely to read it.
