[note: I'm reusing some text here from another post. I am lazy. That is all.
Hi,
It's quite common for bug reports to need some improvement - I mean, it's not fun reporting errors, you've just come across something that's not working correctly so you're not exactly in the best frame of mind, and writing up a detailed report isn't exactly fun. But, it's needed, so after asking around if there was somewhere WoW-specified that has already done this (and not receiving an answer, so there possibly is that I don't know about), I've put up a short list of things you can do to make your bug report as useful as possible:
The main reason I put this up is because when I'm replying to bug reports posted in addon threads, a lot of the time it's just to ask the poster to include some sort of extra information (like the full bug report, or what other addons they're using, or to ask what they've tried already, etc.). Now whenever I would've done this, I will just post the above link (and edit the list to include whatever they're not doing, if it's not already included). I did ask around a few times to see if this sort of thing already existed - and I know about several sites elsewhere on the web that give general advice on the subject, but I couldn't find anything specific to WoW addons. If I have reinvented the wheel I apologise, but hey, two wheels are better than none. Unless that just confuses things, or the second wheel is really badly made and people don't find out about the first wheel, or maybe it was a unicycle competition or something.
So, just posting here to let people know, and of course, to ask for feedback, suggestions, improvements, criticism, and flames.
I'd suggest dir /ad /b "c:\Program Files\World of Warcraft\Interface\Addons\" > c:\myaddons.txt
for the addon listing.
/ad = only include top directories
/b = bare format (you had that one already)
double quotes around the path (command interpreter doesn't like spaces)
> c:\myaddons.txt = redirect the addon listing to a text file for easier inclusion as attachment.
As for critism, I applaud it. Sadly, most people that post bugs in which an author asks for more info are just those people who often neglect to /search or check a wiki, so it's likely it won't change much. But nonetheless, I hope it will be very useful..
Though what is this part doing on the wiki page ?
This uhm, doesn't actually sound like it's an Prat error, and you haven't provided any information yet could show what's going on exactly (although part of the error message is a good start).
Sadly, most people that post bugs in which an author asks for more info are just those people who often neglect to /search or check a wiki, so it's likely it won't change much. But nonetheless, I hope it will be very useful..
Well, yeah, I know what you mean, and I wasn't really expecting the bug reporters to search the wiki on how to report a bug first. (I hadn't until recently!) It was more something that could be used (at least by me) as could be used when replying to incomplete bug reports - instead of having to type out what exactly the poster needs to tell us, just point to that page (and maybe copy + paste the relevant bits).
Though what is this part doing on the wiki page ?
What is what doing on the wiki page? I have no idea what you're talking about, there is nothing of the sort there, your eyes must be deceiving you. Yes. It was never there.
I'd suggest dir /ad /b "c:\Program Files\World of Warcraft\Interface\Addons\" > c:\myaddons.txt
for the addon listing.
/ad = only include top directories
/b = bare format (you had that one already)
double quotes around the path (command interpreter doesn't like spaces)
> c:\myaddons.txt = redirect the addon listing to a text file for easier inclusion as attachment.
I agree with your suggestion. Would you update the page yourself, or should I?
When reporting your bug, state the revision of the addon you are reporting (the revision number is the addon version number). To find the revision number of the addon, you can look in the addon folder for that addon, you will see a file that looks like Changelog-BigWigs-r57382.txt, the r57382 is the revision number of the addon.
I think that's a great idea, Fin. Most people probably don't know what info really needs to be included in a bug report unless they have actually been involved in QC'ing software. Hopefully it'll make for a few less headaches all around.
I know wikis are collaborative endeavors but I still have some inhibitions about editing someone else's public page :)
Either way is fine.
Please, go ahead and update it! If it's a major change, I think it's polite to write something in the discussion page of an article to explain your reasoning, but otherwise all that's needed is a note in the edit log. :)
However, lazy contributions are better than no contributions, so I'm happy to update it for you if you like. :)
I took the Prat stuff out of the wiki page today. It was left over from the copy/paste from the Prat thread.
Huh. I'd swear I removed that before replying to Xinhuan's post - I was only joking when I said that it was never there. :) Of course it was there, I fucked up and pasted too much from my original post in the Prat thread, yes, and was making one of my hilarious witty hahas by fixing the page and pretending that I'd never fucked up in the first place. But, huh, wow, just checked the edit log and apparently that didn't happen. Hello! I'm Fin and I'm: tired.
While you're tired, I admire your effort to "hide" an error, but still I saw it :P Just didn't know if you left it there as a joke or not, which is why I didn't edit it myself. Seerah did as she said.
I like it, but it needs some work. I'll be moving the page to a better name soon.
What I think needs done:
* Less "Wall of text"... divide it out into short, concise, logical sections.
* Put a MAJOR emphasis on getting bug reports to the right place. Many users don't realize that posting to a forum thread is not enough for me. I read it, I might even think it's a great idea, and then the next time I sit down and work on the addon I forget all about it cause it's not on my tracker. Providing good reports don't do shit if it's not in the right place.
* Provide LINKS!
* Help people read the debug stack a tad... embed reports often go to the wrong place... would be good ta make the user aware that the issue may not be with the mod reporting it
While you're tired, I admire your effort to "hide" an error, but still I saw it :P Just didn't know if you left it there as a joke or not, which is why I didn't edit it myself. Seerah did as she said.
This is as humour-free as I can make it:
When I created the page, I made a mistake and pasted the extra line that was part of my post and should not have been on the wiki article. You caught the mistake, and said something here. When I read your post, I went to the wiki page and removed the offending line - or so I thought - and then replied to your post in a deliberately unconvincing manner claiming that the error had never existed. However, because I was tired I had not edited the page at all. Later Seerah corrected this.
My sincere apologies for attempting to be funny when I should really know better.
I like it, but it needs some work. I'll be moving the page to a better name soon.
I actually thought about this quite a lot (as you will see from the small essay below), and it was a while before I chose "Reporting_Bugs". While I respect your right to change it to whatever you consider a better name, would you at least please invite comments? At least for me. :)
Just to let you know my train of thought: I wanted the name of the article to be descriptive, accurate, easy to remember, and relevant.
(I was anticipating using the URL in replies to bug reports where it would be useful for the author to improve them in some way, possibly quite often. I imagined my replies as being simply the URL, although maybe with some of the article copied + pasted if it was specifically relevant or particularly helpful - so I tried to pick a title that would immediately show what it was about; I wanted it to be accurate, because if someone clicked the link and saw something that didn't fit the title, they wouldn't even get to the content of the article before becoming confused about it. I also hoped that it might be something that people found useful enough to recommend so it had to be simple enough to remember easily, or at least simple enough that it was easy to find again. And, relevant, because again as I wanted to use the article URL as a post in itself, I tried to think of something that would make sense as a response to different types of posts - or at least, not not make sense as a reply.)
First I thought of things like "How to write good bug reports" or "Tips on writing good bug reports". I chose "Writing bug reports" because it was shorter, basically. However it's a bit formal and would be more appropriate to more in-depth look at writing bug reports than the short helper list I was hoping would actually be read by the people writing the reports. It's also probably not as likely to be found again as something including the phrase "bug reports", as "Reporting bugs" is slightly different - not as commonly used so not as likely to be the first thing the comes into someone's mind when they've forgotten the actual title.
(I actually had the same problem again when thinking of the subject of this post (which has different criteria, slightly).)
So! I would say that if the title were to be changed, I would use "Writing Good Bug Reports" (possibly substituting "Good" with something that might seem more applicable - maybe Quality or Useful. I dunno). It's fairly short, easy to search for, descriptive, hopefully accurate, and more likely to imply a list of tips rather than an in-depth tutorial.
Choo choo! The train has arrived and thank fuck for that.
Quote from tekkub »
What I think needs done:
* Less "Wall of text"... divide it out into short, concise, logical sections.
Yeah, very true - the formatting needs work for sure. (If it'd been a plain text file I would've done a much better job! If it'd been a plain HTML file I would've too! Bloody wiki markup though, I don't write enough to remember all the little bits off the top of my head.)
One thing is perhaps to make the main points at the top, with the more detailed and possibly less relevant or important advice below.
Quote from tekkub »
* Put a MAJOR emphasis on getting bug reports to the right place. Many users don't realize that posting to a forum thread is not enough for me. I read it, I might even think it's a great idea, and then the next time I sit down and work on the addon I forget all about it cause it's not on my tracker. Providing good reports don't do shit if it's not in the right place.
That's very true, yes. However I did want to make it specific to WoWAce in particular, and I would have to say that the forum thread is the place to report bugs for most of the addons I know of. Don't read that to mean that I don't agree with you about emphasising the importance of where the bug is reported - I mean, I just did agree with you in my previous sentence :) - but I'm not sure that such a MAJOR emphasis is a good idea; just emphasis, maybe. :) I'm not sure it's a good idea to attempt to make something that covered all WoW addons in general (even though it may largely be useful in general) because it would make it necessary to include more information about the different possible ways of reporting bugs and what is expected from whom, while also limiting the detail of the advice given
Perhaps putting something like:
MAKE SUREyou are reporting your bug in the right place.
For example, if you are reporting your bug in a forum thread, this may not be checked by the addon author in the near future - or at all - as some developers use alternative methods for tracking bugs. See below for some places to check if you're not certain that the developer will be checking wherever you are posting your report.
?
Quote from tekkub »
* Provide LINKS!
* Help people read the debug stack a tad... embed reports often go to the wrong place... would be good ta make the user aware that the issue may not be with the mod reporting it
Don't name a wiki page based on the URL you will get, that's what redirects are for. Example: http://www.wowwiki.com/WW:EL
Hell, make more redirects if you want, they're super easy in MediaWiki.
If you rambled less here and more on the wiki page, it would be done already :P
What is this "rambled" you speak of? I think I may have heard of it, tell me more.
[edit]
What I meant to say was, of course:
Excellent. I am a big fan of multiple helpful redirects (or, aliases I'd call WoWWik's impementation, as the user isn't actually redirected (even though the server is internally)). It did cross my mind that redirects would be useful, but I didn't realise that an admin wouldn't be needed to create and maintain them. (I have actually created one myself a month or so ago, and remember being surprised that I was able to do this myself. Not surprised enough to connect the possibility to do so when it was actually relevant, I guess, but hey.)
Now about this rambo thing you mentioned...
[/edit]
Hi,
It's quite common for bug reports to need some improvement - I mean, it's not fun reporting errors, you've just come across something that's not working correctly so you're not exactly in the best frame of mind, and writing up a detailed report isn't exactly fun. But, it's needed, so after asking around if there was somewhere WoW-specified that has already done this (and not receiving an answer, so there possibly is that I don't know about), I've put up a short list of things you can do to make your bug report as useful as possible:
- http://wowace.com/wiki/Reporting_Bugs
The main reason I put this up is because when I'm replying to bug reports posted in addon threads, a lot of the time it's just to ask the poster to include some sort of extra information (like the full bug report, or what other addons they're using, or to ask what they've tried already, etc.). Now whenever I would've done this, I will just post the above link (and edit the list to include whatever they're not doing, if it's not already included). I did ask around a few times to see if this sort of thing already existed - and I know about several sites elsewhere on the web that give general advice on the subject, but I couldn't find anything specific to WoW addons. If I have reinvented the wheel I apologise, but hey, two wheels are better than none. Unless that just confuses things, or the second wheel is really badly made and people don't find out about the first wheel, or maybe it was a unicycle competition or something.
So, just posting here to let people know, and of course, to ask for feedback, suggestions, improvements, criticism, and flames.
cheers,
- Fin
I'd suggest
dir /ad /b "c:\Program Files\World of Warcraft\Interface\Addons\" > c:\myaddons.txt
for the addon listing.
/ad = only include top directories
/b = bare format (you had that one already)
double quotes around the path (command interpreter doesn't like spaces)
> c:\myaddons.txt = redirect the addon listing to a text file for easier inclusion as attachment.
Though what is this part doing on the wiki page ?
Well, yeah, I know what you mean, and I wasn't really expecting the bug reporters to search the wiki on how to report a bug first. (I hadn't until recently!) It was more something that could be used (at least by me) as could be used when replying to incomplete bug reports - instead of having to type out what exactly the poster needs to tell us, just point to that page (and maybe copy + paste the relevant bits).
What is what doing on the wiki page? I have no idea what you're talking about, there is nothing of the sort there, your eyes must be deceiving you. Yes. It was never there.
I agree with your suggestion. Would you update the page yourself, or should I?
Either way is fine.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhen reporting your bug, state the revision of the addon you are reporting (the revision number is the addon version number). To find the revision number of the addon, you can look in the addon folder for that addon, you will see a file that looks like Changelog-BigWigs-r57382.txt, the r57382 is the revision number of the addon.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI think that's a great idea, Fin. Most people probably don't know what info really needs to be included in a bug report unless they have actually been involved in QC'ing software. Hopefully it'll make for a few less headaches all around.
Please, go ahead and update it! If it's a major change, I think it's polite to write something in the discussion page of an article to explain your reasoning, but otherwise all that's needed is a note in the edit log. :)
However, lazy contributions are better than no contributions, so I'm happy to update it for you if you like. :)
Huh. I'd swear I removed that before replying to Xinhuan's post - I was only joking when I said that it was never there. :) Of course it was there, I fucked up and pasted too much from my original post in the Prat thread, yes, and was making one of my hilarious witty hahas by fixing the page and pretending that I'd never fucked up in the first place. But, huh, wow, just checked the edit log and apparently that didn't happen. Hello! I'm Fin and I'm: tired.
While you're tired, I admire your effort to "hide" an error, but still I saw it :P Just didn't know if you left it there as a joke or not, which is why I didn't edit it myself. Seerah did as she said.
What I think needs done:
* Less "Wall of text"... divide it out into short, concise, logical sections.
* Put a MAJOR emphasis on getting bug reports to the right place. Many users don't realize that posting to a forum thread is not enough for me. I read it, I might even think it's a great idea, and then the next time I sit down and work on the addon I forget all about it cause it's not on my tracker. Providing good reports don't do shit if it's not in the right place.
* Provide LINKS!
* Help people read the debug stack a tad... embed reports often go to the wrong place... would be good ta make the user aware that the issue may not be with the mod reporting it
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis is as humour-free as I can make it:
When I created the page, I made a mistake and pasted the extra line that was part of my post and should not have been on the wiki article. You caught the mistake, and said something here. When I read your post, I went to the wiki page and removed the offending line - or so I thought - and then replied to your post in a deliberately unconvincing manner claiming that the error had never existed. However, because I was tired I had not edited the page at all. Later Seerah corrected this.
My sincere apologies for attempting to be funny when I should really know better.
I actually thought about this quite a lot (as you will see from the small essay below), and it was a while before I chose "Reporting_Bugs". While I respect your right to change it to whatever you consider a better name, would you at least please invite comments? At least for me. :)
Just to let you know my train of thought: I wanted the name of the article to be descriptive, accurate, easy to remember, and relevant.
(I was anticipating using the URL in replies to bug reports where it would be useful for the author to improve them in some way, possibly quite often. I imagined my replies as being simply the URL, although maybe with some of the article copied + pasted if it was specifically relevant or particularly helpful - so I tried to pick a title that would immediately show what it was about; I wanted it to be accurate, because if someone clicked the link and saw something that didn't fit the title, they wouldn't even get to the content of the article before becoming confused about it. I also hoped that it might be something that people found useful enough to recommend so it had to be simple enough to remember easily, or at least simple enough that it was easy to find again. And, relevant, because again as I wanted to use the article URL as a post in itself, I tried to think of something that would make sense as a response to different types of posts - or at least, not not make sense as a reply.)
First I thought of things like "How to write good bug reports" or "Tips on writing good bug reports". I chose "Writing bug reports" because it was shorter, basically. However it's a bit formal and would be more appropriate to more in-depth look at writing bug reports than the short helper list I was hoping would actually be read by the people writing the reports. It's also probably not as likely to be found again as something including the phrase "bug reports", as "Reporting bugs" is slightly different - not as commonly used so not as likely to be the first thing the comes into someone's mind when they've forgotten the actual title.
(I actually had the same problem again when thinking of the subject of this post (which has different criteria, slightly).)
So! I would say that if the title were to be changed, I would use "Writing Good Bug Reports" (possibly substituting "Good" with something that might seem more applicable - maybe Quality or Useful. I dunno). It's fairly short, easy to search for, descriptive, hopefully accurate, and more likely to imply a list of tips rather than an in-depth tutorial.
Choo choo! The train has arrived and thank fuck for that.
Yeah, very true - the formatting needs work for sure. (If it'd been a plain text file I would've done a much better job! If it'd been a plain HTML file I would've too! Bloody wiki markup though, I don't write enough to remember all the little bits off the top of my head.)
One thing is perhaps to make the main points at the top, with the more detailed and possibly less relevant or important advice below.
That's very true, yes. However I did want to make it specific to WoWAce in particular, and I would have to say that the forum thread is the place to report bugs for most of the addons I know of. Don't read that to mean that I don't agree with you about emphasising the importance of where the bug is reported - I mean, I just did agree with you in my previous sentence :) - but I'm not sure that such a MAJOR emphasis is a good idea; just emphasis, maybe. :) I'm not sure it's a good idea to attempt to make something that covered all WoW addons in general (even though it may largely be useful in general) because it would make it necessary to include more information about the different possible ways of reporting bugs and what is expected from whom, while also limiting the detail of the advice given
Perhaps putting something like:
?
Thanks Tekkub, these are all great suggestions.
[b]Fight back![/b] Make that wall of text
[b]Kick it![/b] Punch it! Swing the Mighty Rod of Effective Technical Writing at its vast and shapeless form!
Even the most [b]impenetrable[/b] of wordstorms have their weaknesses, and [b]this one is no different[/b].
[b]It can be done[/b]. The wall of text will fall, leaving the path clear to the golden treasure awaiting beyond. Finally.
It must be so! For it is written.
Hell, make more redirects if you want, they're super easy in MediaWiki.
If you rambled less here and more on the wiki page, it would be done already :P
What is this "rambled" you speak of? I think I may have heard of it, tell me more.
[edit]
What I meant to say was, of course:
Excellent. I am a big fan of multiple helpful redirects (or, aliases I'd call WoWWik's impementation, as the user isn't actually redirected (even though the server is internally)). It did cross my mind that redirects would be useful, but I didn't realise that an admin wouldn't be needed to create and maintain them. (I have actually created one myself a month or so ago, and remember being surprised that I was able to do this myself. Not surprised enough to connect the possibility to do so when it was actually relevant, I guess, but hey.)
Now about this rambo thing you mentioned...
[/edit]
:)