Re: Support suggestions - long (was politeness, et al)
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 25956
interpreted = N
texte = Interesting, a bug tracking system like this sounds like Bugzilla, for the Mozilla web browser. Having alpha tested Mozilla, I can tell you that the system is very effective, but will require a significant commitment on the part of SM to remain current. At this point, I for one am skeptical that they'd be willing to take the time to implment the great solution you provided.Chris >Ok here are some positive suggestions, most are simply extensions of basic >software development bug tracking methodology. To support WebCat, it only >seems logical to use a WebCat driven support solution so... > >Consider for a moment that all problems can be broken down and identified >into these basic classifications: >A. a user error in implementing a *well* documented operation - essentially >a user bug >B. a user error in implementing a poorly or non documented operation - >which is a documentation bug. >C. a performance error where a properly implemented operation does not >perform as expected - which is a true software bug > >Now, now build a WebCat driven, publicly accessible bug/issue database and >implement the following support procedures: > >1. A user posts the relevent details of their problem to the talk list. >2. Fellow users *and* SM tech support provide initial support *and* a >determination is made as to whether this issue is a user bug, a docs bug, >or a software bug. Issues are entered in to the database and actions are >taken based upon their classification. > >User Bugs: >Most all users bugs should be able to be satisfied by support staff & users >via the list. However, if it is a user bug that repeatedly comes up then >it should be classified as a docs bug and logged into your bug database and >either addressed by way of changes to the docs or added to a comprehensive >set of FAQs. Additionally, if the user cannot get resolution by support >staff & users then the issue should be able to be added to the bug database >by the user and addressed by development staff. > >Docs Bugs: >These are pretty straightforward and should be able to be addressed by >non-development resources by way of updating the on-line docs, >creating/expanding a comprehensive set of FAQs, or written into example >code. > >Software Bugs: >These will of course require development resources to identify and correct. >The status on the bug and the fixes should be publicly available via the >database. > >The key to this whole concept is to open up a bug/issue tracking database >and utilize it. Not all user bugs need to be logged into the bug database >(since almost all will be addressed via the list) but if the issue is not >being resolved/addressed by SM or the talklist then there should be a way >to be able to log this in and get it addressed by more >knowledgable/responsive people. All docs bugs & software bugs should be >logged into the support database as well, which should be made available to >the users so that we may: A. feel like the issue is being addressed, B. >check the status of the outstanding issue, C. check the database to see if >someone else has already reported/resolved the same issue. > >In the old days, the list archives provided the basic functionality of a >bug tracking database. But now WebCat is far too complex, on too many >platforms, and the volume of list traffic is far too high for the archives >to be as effective as they once were. A bug tracking database would give us >the ability to condense this information into a much more useful and >trackable form and would assure that *no* issues were left to fall through >the cracks. > >The bug tracking database would also make much more effective use of >development resources when they all called on to provide user support >because the bug report would contain all the relevent information for >development staff to quickly isolate the issue ie: WebCat version#, >platform, OS, memory settings, exact snippets of the problem WebDNA etc >etc. Additionally, and depending on your staffing levels, the bug reports >could be filtered through QA to recreate and validate the bug (in case of a >claimed SW bug) after passing through tech support - and prior to >assigning it to be addressed by an engineer. > >So in a nutshell: The talk list would be used to resolve >user/implementation issues and act as a filter for engineering. *IF* an >issue is not/cannot be resolved via the list then it is elevated by the >user into the bug tracking/support database for addressing by >QA/Engineering and the issue's status and resolution is available for >viewing/searching. > >I hope that makes some sense. >Marty Schmid > > > > >------------------------------------------------------------- >Brought to you by CommuniGate Pro - The Buzz Word Compliant Messaging Server. >To end your Mail problems go to
. > >This message is sent to you because you are subscribed to > the mailing list . >To unsubscribe, E-mail to: >To switch to the DIGEST mode, E-mail to > Christopher Feyrer System Administrator FoodSpot.com chris@foodspot.com ------------------- PGP 6.x key available.------------------------------------------------------------- Brought to you by CommuniGate Pro - The Buzz Word Compliant Messaging Server. To end your Mail problems go to .This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to
Associated Messages, from the most recent to the oldest:
Interesting, a bug tracking system like this sounds like Bugzilla, for the Mozilla web browser. Having alpha tested Mozilla, I can tell you that the system is very effective, but will require a significant commitment on the part of SM to remain current. At this point, I for one am skeptical that they'd be willing to take the time to implment the great solution you provided.Chris >Ok here are some positive suggestions, most are simply extensions of basic >software development bug tracking methodology. To support WebCat, it only >seems logical to use a WebCat driven support solution so... > >Consider for a moment that all problems can be broken down and identified >into these basic classifications: >A. a user error in implementing a *well* documented operation - essentially >a user bug >B. a user error in implementing a poorly or non documented operation - >which is a documentation bug. >C. a performance error where a properly implemented operation does not >perform as expected - which is a true software bug > >Now, now build a WebCat driven, publicly accessible bug/issue database and >implement the following support procedures: > >1. A user posts the relevent details of their problem to the Talk List. >2. Fellow users *and* SM tech support provide initial support *and* a >determination is made as to whether this issue is a user bug, a docs bug, >or a software bug. Issues are entered in to the database and actions are >taken based upon their classification. > >User Bugs: >Most all users bugs should be able to be satisfied by support staff & users >via the list. However, if it is a user bug that repeatedly comes up then >it should be classified as a docs bug and logged into your bug database and >either addressed by way of changes to the docs or added to a comprehensive >set of FAQs. Additionally, if the user cannot get resolution by support >staff & users then the issue should be able to be added to the bug database >by the user and addressed by development staff. > >Docs Bugs: >These are pretty straightforward and should be able to be addressed by >non-development resources by way of updating the on-line docs, >creating/expanding a comprehensive set of FAQs, or written into example >code. > >Software Bugs: >These will of course require development resources to identify and correct. >The status on the bug and the fixes should be publicly available via the >database. > >The key to this whole concept is to open up a bug/issue tracking database >and utilize it. Not all user bugs need to be logged into the bug database >(since almost all will be addressed via the list) but if the issue is not >being resolved/addressed by SM or the talklist then there should be a way >to be able to log this in and get it addressed by more >knowledgable/responsive people. All docs bugs & software bugs should be >logged into the support database as well, which should be made available to >the users so that we may: A. feel like the issue is being addressed, B. >check the status of the outstanding issue, C. check the database to see if >someone else has already reported/resolved the same issue. > >In the old days, the list archives provided the basic functionality of a >bug tracking database. But now WebCat is far too complex, on too many >platforms, and the volume of list traffic is far too high for the archives >to be as effective as they once were. A bug tracking database would give us >the ability to condense this information into a much more useful and >trackable form and would assure that *no* issues were left to fall through >the cracks. > >The bug tracking database would also make much more effective use of >development resources when they all called on to provide user support >because the bug report would contain all the relevent information for >development staff to quickly isolate the issue ie: WebCat version#, >platform, OS, memory settings, exact snippets of the problem WebDNA etc >etc. Additionally, and depending on your staffing levels, the bug reports >could be filtered through QA to recreate and validate the bug (in case of a >claimed SW bug) after passing through tech support - and prior to >assigning it to be addressed by an engineer. > >So in a nutshell: The Talk List would be used to resolve >user/implementation issues and act as a filter for engineering. *IF* an >issue is not/cannot be resolved via the list then it is elevated by the >user into the bug tracking/support database for addressing by >QA/Engineering and the issue's status and resolution is available for >viewing/searching. > >I hope that makes some sense. >Marty Schmid > > > > >------------------------------------------------------------- >Brought to you by CommuniGate Pro - The Buzz Word Compliant Messaging Server. >To end your Mail problems go to . > >This message is sent to you because you are subscribed to > the mailing list . >To unsubscribe, E-mail to: >To switch to the DIGEST mode, E-mail to > Christopher Feyrer System Administrator FoodSpot.com chris@foodspot.com ------------------- PGP 6.x key available.------------------------------------------------------------- Brought to you by CommuniGate Pro - The Buzz Word Compliant Messaging Server. To end your Mail problems go to .This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to
Christopher Feyrer
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
WebDelivery: One step closer !! (1997)
Size limit for tmpl editor ? (1997)
Access Denied! But why? (1997)
Hosts who have upgraded to v5.0? (2003)
what does [url] copy [/url] really do? (2000)
Dark Horse Comics success story (1997)
Running 2 two WebCatalog.acgi's (1996)
Reload adding to cart (2001)
Sorting Numbers (1997)
Grep and Special Characters (2002)
Problems with cybercash (2000)
Emailer port change (1997)
WebCatalog as a ListServ (1998)
TCP Connect code for SMTP transaction (2004)
Username for Admin Group (1997)
WC1.6 to WC2 date formatting (1997)
AuthorizeNet and SIM (2002)
writing db to disk (1997)
PCS Frames (1997)
New command suggestion (1997)