However, if Spennig's idea didn't make the final cut, that is something that would need to be considered. If the errors were automatically reported, how is the author to know (unless it's a very obvious change on the user end) that the user is mucking around with stuff, and this isn't a problem with the code as it is on the svn?
Maybe have there be a form from either end that allows a checkbox for "user modified" to let authors and devs know that the user was playing.
I'm not great at coding or such, but I web/forum admin my guild site and a community site :) i've learned to work the web-love... with help.
Well, then it could be covered by "auto with curse client if average user" and "manual through site-upload if power-user", the automated can be a default setting during the curse install. Most power-users read install options rather carefully anyhow :)
(Was a very good point though, we need to talk more again on xfire young lady!)
1) Collect data anonymously, and without distubing the user.
2) Collect data and associate it with a particular user. They would notified about the error and what data was being sent, the be given the option of sending it themself or letting the report gathering take place automatically.
The first use lets you answer "how common is this issue"
The second lets you know who is haveing this issue, so you can obtain further information.
1) Collect data anonymously, and without distubing the user.
2) Collect data and associate it with a particular user. They would notified about the error and what data was being sent, the be given the option of sending it themself or letting the report gathering take place automatically.
The first use lets you answer "how common is this issue"
The second lets you know who is haveing this issue, so you can obtain further information.
Add the option for "I don't want to do this" someplace before some of the power users who don't like "having" to do anything can say no.
Any system like this would be completely optional.
::grins:: -I- know this, but after the flood of "WTF CC is not letting me say no" posts, I figured saying it for the intellectually impaired would be good.
::grins:: -I- know this, but after the flood of "WTF CC is not letting me say no" posts, I figured saying it for the intellectually impaired would be good.
Heh, much of the CC's problems originate from UI design issues. It's UI in general needs to be refactored so that it is more intuitive and interactive with the user.
Heh, much of the CC's problems originate from UI design issues. It's UI in general needs to be refactored so that it is more intuitive and interactive with the user.
So basically it's like throwing a Linux command-line guy at an X-Windows program and saying "Make it work"? :D
this reminds me of warcraftrealms, their addon already takes census data from the SV folder results of the addon, and produces some intriguing data over time, etc. so, the idea isn't new, it's just in need of a few core systems to organise it, perhaps by breaking a few existing system into something that will work.
if you integrate more detailed bug info with a bugsack like addon, i.e. date/time, addons loaded, revision versions of each, etc. and dump it into an open session log, curseupdater can read it, upload it with the other user profile data it collects, and put it in a regular sql database (ideally a temporary one at first, then a separate bugDB)
since curse can run in the background, it can return viable data quickly, i.e. within minutes of an event once the data is saved outside of the game.
once you have a temporary submission system in place for the server, you can open up a window or an in-game chatlog item from the bugtraq (sic) addon to ask users what happened, or what they clicked on, etc. possibly it could read a flag inside your svn version info for compulsory nagging, or you could include the addon in your working/test copy on the curse site, etc.
after that, either attach the submission entries to a ticket system, or, have the bugtraq entry readable on the developer's sub-site, with searchable criteria, i.e. have a blog or bugtraq system, link into an open submission database that can parse say, the 300-500 submissions for an addon, and pare the number down to say the 20 most recent, 20 most frequent, the number/chronology of purely identical errors, across revisions, all those brand new errors, oldest errors seen, number recorded this week, last week, today,etc., etc. with graphs, etc.
Ok, step 1 will be gathering error data from the wow client. Lets start with the information which can go into both the anonymous and non-anonymous systems.
The choices are:
Write an error handler addon
Write an addon that gets data from error handler addons
The least disruptive option is #2. However we may not be able to get data at the time of the error. This pretty much means collecting data from Bugrabber and Swatter.
The data to be collected:
Per session:
Starting list of addons, and thier status (How would we know thier version)
Locale
Starting Time
Per error:
Debug Stack from the error
Updated addon statuses (differential from starting status)
Time Delta
Thats just a starting list. What other data would be useful?
Also we may need to consider the size of the data we are storing at the client. Especially if they aren't using an automated upload system.
Would the system be incremental? ie. If they reload thier UI would the client send up any new errors.
Do we want to support messaging back to the client for errors which are identified as known? (This can probably wait until we can even get the errors)
Write an addon that gets data from error handler addons
The least disruptive option is #2. However we may not be able to get data at the time of the error. This pretty much means collecting data from Bugrabber and Swatter.
I would really think hard about who this is being targeted to at this point. The average Joe User may not even have Bugrabber, though Swatter is a good possibility since it comes with the Auc Suite.
If this isn't being rolled into CC, is anyone other than a power-user going to utilize it anyway? I am just wondering if it was ever determined whether it was being rolled into CC. (Apologies, I read the whole thread once, kinda tired right now, and don't remember if this was decided for sure.) If you're rolling it out to power-users, might as well make it an error handler in itself and add maybe add a notes field for them to put what they were doing (if it wasn't on load) and submit that as well.
IMO, sylv, get togeather with rabbit and the Auctioneer people and setup a entirely new addon for this. Let this new addon either replace (prolly not viable) or interact with the other 2 to store & or Record the error logs & associated data (Addon list, versions ect). That way the CC or other can upload that information.
I think the best way would be parse though the stack trace for the first 2 or 3 addons involved by directory. Then on the online interaction, send messages to addons involved (special handling for embedded libs, thos authors shouldn't be notified) Then let the authors figure it out from there. Then again we'd have to black list a few addons to start, like Ace2-3/Rock because it's likely they will be the most affected by spam.
I would really think hard about who this is being targeted to at this point. The average Joe User may not even have Bugrabber, though Swatter is a good possibility since it comes with the Auc Suite.
If this isn't being rolled into CC, is anyone other than a power-user going to utilize it anyway? I am just wondering if it was ever determined whether it was being rolled into CC. (Apologies, I read the whole thread once, kinda tired right now, and don't remember if this was decided for sure.) If you're rolling it out to power-users, might as well make it an error handler in itself and add maybe add a notes field for them to put what they were doing (if it wasn't on load) and submit that as well.
From my perspective its an open discussion and there haven't been any decisions. Thats a couple steps ahead of where i was at.
Lets assume now that we have captured the date as I outlined into a known format in the saved variables of our error collecting addon. Leaving out the details of its transmission, lets say the end user uploads the file via web form submission.
What are the server side issues?
User identity - do we use unique ID's for each submission, or do we make user+submission unique allowing you to aggregate reports from the same user, or do we make both user and submission unique. is an indirect referince ID good enough, ie user#3424524 submission#34234235 (To clarify, I mean from the perspective of the viewers of the errors)
Error identity - its likely that the same error can create many different stack traces. Do we store them all? Do we set an initial threshold, then allow further collection if someone indicates they are interested. Is the top line good enough?
Notification of interested parties. What's the best way to do this. Often a problem can be solved by people other than the author. This part will probably take the most thought, as its the ultimate end of the process. This isnt something that's easily automated in a meaningful way.
Today, we have users posting stack's they cut and paste from the game in an addon's forum thread. Many times those posts are misdirected.
So...One idea would be to have all errors feeding into a single stream. Where anyone can look to see what errors are occuring, and provide additional info say add hints or "tag" them as belonging to addonX (which could be thier addon or someone elses). An error can have an arbitrary number of tags they would be non-exclusive.
This manual tagging could be in addition to automated tagging based on the call stack, or faulting addon.
Also the same process works for an author who wants to untag his addon from an error.
Also its only via tagging that you can view detail beyond the debug stack. Ie. the information would be marked as having been viewed by you. And the "who looked at this" part would stay public. I think that the best method of securing things would be to make their access publically viewable.
The remaining "unclaimed" errors would be accumulated - possibly dumping all the additional information, and just keeping the stack.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMaybe have there be a form from either end that allows a checkbox for "user modified" to let authors and devs know that the user was playing.
I'm not great at coding or such, but I web/forum admin my guild site and a community site :) i've learned to work the web-love... with help.
(Was a very good point though, we need to talk more again on xfire young lady!)
-
View User Profile
-
View Posts
-
Send Message
Curse Premium(Yes we do. I think you are awake when I'm asleep though, since you are keeping working hours now.)
-
View User Profile
-
View Posts
-
Send Message
Curse Premium1) Collect data anonymously, and without distubing the user.
2) Collect data and associate it with a particular user. They would notified about the error and what data was being sent, the be given the option of sending it themself or letting the report gathering take place automatically.
The first use lets you answer "how common is this issue"
The second lets you know who is haveing this issue, so you can obtain further information.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAdd the option for "I don't want to do this" someplace before some of the power users who don't like "having" to do anything can say no.
Any system like this would be completely optional.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium::grins:: -I- know this, but after the flood of "WTF CC is not letting me say no" posts, I figured saying it for the intellectually impaired would be good.
Heh, much of the CC's problems originate from UI design issues. It's UI in general needs to be refactored so that it is more intuitive and interactive with the user.
-
View User Profile
-
View Posts
-
Send Message
Project AuthorSo basically it's like throwing a Linux command-line guy at an X-Windows program and saying "Make it work"? :D
Actually it was more like taking a reverse engineer and high performance backend server developer and saying "Make a GUI"!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThen you have to get rid of the bodies and to hire two new engineers. :p
-
View User Profile
-
View Posts
-
Send Message
Project AuthorOr like taking an Algebra student, throwing a Lua book at him, and saying "Make an addon"? :)
if you integrate more detailed bug info with a bugsack like addon, i.e. date/time, addons loaded, revision versions of each, etc. and dump it into an open session log, curseupdater can read it, upload it with the other user profile data it collects, and put it in a regular sql database (ideally a temporary one at first, then a separate bugDB)
since curse can run in the background, it can return viable data quickly, i.e. within minutes of an event once the data is saved outside of the game.
once you have a temporary submission system in place for the server, you can open up a window or an in-game chatlog item from the bugtraq (sic) addon to ask users what happened, or what they clicked on, etc. possibly it could read a flag inside your svn version info for compulsory nagging, or you could include the addon in your working/test copy on the curse site, etc.
after that, either attach the submission entries to a ticket system, or, have the bugtraq entry readable on the developer's sub-site, with searchable criteria, i.e. have a blog or bugtraq system, link into an open submission database that can parse say, the 300-500 submissions for an addon, and pare the number down to say the 20 most recent, 20 most frequent, the number/chronology of purely identical errors, across revisions, all those brand new errors, oldest errors seen, number recorded this week, last week, today,etc., etc. with graphs, etc.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe choices are:
- Write an error handler addon
- Write an addon that gets data from error handler addons
The least disruptive option is #2. However we may not be able to get data at the time of the error. This pretty much means collecting data from Bugrabber and Swatter.The data to be collected:
Per session:
- Starting list of addons, and thier status (How would we know thier version)
- Locale
- Starting Time
Per error:- Debug Stack from the error
- Updated addon statuses (differential from starting status)
- Time Delta
Thats just a starting list. What other data would be useful?Also we may need to consider the size of the data we are storing at the client. Especially if they aren't using an automated upload system.
Would the system be incremental? ie. If they reload thier UI would the client send up any new errors.
Do we want to support messaging back to the client for errors which are identified as known? (This can probably wait until we can even get the errors)
-
View User Profile
-
View Posts
-
Send Message
Project Author...with a disclaimer that SV content, depending on what addons they are using, may reveal private information.
This is true, but for some bugs this would be invaluable to fixing them.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI would really think hard about who this is being targeted to at this point. The average Joe User may not even have Bugrabber, though Swatter is a good possibility since it comes with the Auc Suite.
If this isn't being rolled into CC, is anyone other than a power-user going to utilize it anyway? I am just wondering if it was ever determined whether it was being rolled into CC. (Apologies, I read the whole thread once, kinda tired right now, and don't remember if this was decided for sure.) If you're rolling it out to power-users, might as well make it an error handler in itself and add maybe add a notes field for them to put what they were doing (if it wasn't on load) and submit that as well.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI think the best way would be parse though the stack trace for the first 2 or 3 addons involved by directory. Then on the online interaction, send messages to addons involved (special handling for embedded libs, thos authors shouldn't be notified) Then let the authors figure it out from there. Then again we'd have to black list a few addons to start, like Ace2-3/Rock because it's likely they will be the most affected by spam.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumFrom my perspective its an open discussion and there haven't been any decisions. Thats a couple steps ahead of where i was at.
Lets assume now that we have captured the date as I outlined into a known format in the saved variables of our error collecting addon. Leaving out the details of its transmission, lets say the end user uploads the file via web form submission.
What are the server side issues?
- User identity - do we use unique ID's for each submission, or do we make user+submission unique allowing you to aggregate reports from the same user, or do we make both user and submission unique. is an indirect referince ID good enough, ie user#3424524 submission#34234235 (To clarify, I mean from the perspective of the viewers of the errors)
- Error identity - its likely that the same error can create many different stack traces. Do we store them all? Do we set an initial threshold, then allow further collection if someone indicates they are interested. Is the top line good enough?
- Notification of interested parties. What's the best way to do this. Often a problem can be solved by people other than the author. This part will probably take the most thought, as its the ultimate end of the process. This isnt something that's easily automated in a meaningful way.
Today, we have users posting stack's they cut and paste from the game in an addon's forum thread. Many times those posts are misdirected.So...One idea would be to have all errors feeding into a single stream. Where anyone can look to see what errors are occuring, and provide additional info say add hints or "tag" them as belonging to addonX (which could be thier addon or someone elses). An error can have an arbitrary number of tags they would be non-exclusive.
This manual tagging could be in addition to automated tagging based on the call stack, or faulting addon.
Also the same process works for an author who wants to untag his addon from an error.
Also its only via tagging that you can view detail beyond the debug stack. Ie. the information would be marked as having been viewed by you. And the "who looked at this" part would stay public. I think that the best method of securing things would be to make their access publically viewable.
The remaining "unclaimed" errors would be accumulated - possibly dumping all the additional information, and just keeping the stack.