Support suggestions - long (was politeness, et al)
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 25954
interpreted = N
texte = 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 bugNow, 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
Associated Messages, from the most recent to the oldest:
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 bugNow, 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
Marty Schmid
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:
triggering an update of two frames (1998)
Webcatalog 4.01 and Webstar 4.2.1, is it OK? (2000)
Appendfile memory usage (redux) (2003)
Real Audio files (1997)
Question (1998)
2.0Beta Command Ref (can't find this instruction) (1997)
Email within tmpl ? (1997)
page redirect in webDNA (1997)
ErrorLog with Linux? (2000)
RE: MS Commerce Comparison (long) (1998)
Replace context problem ... (1997)
locking variables? (2000)
Freeze (2003)
Country & Ship-to address & other fields ? (1997)
Monthly Help File (2000)
WC2/Mac -- Forms not submitting correctly with Mac browsers (1997)
[WebDNA] slideshow (2008)
RE: Problems reading files created by WC (1997)
Include a big block of text (1997)
Make sure I understand this??? (1997)