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 theMozilla web browser. Having alpha tested Mozilla, I can tell you that thesystem is very effective, but will require a significant commitment on thepart of SM to remain current. At this point, I for one am skeptical thatthey'd be willing to take the time to implment the great solution youprovided.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 FeyrerSystem AdministratorFoodSpot.comchris@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 theMozilla web browser. Having alpha tested Mozilla, I can tell you that thesystem is very effective, but will require a significant commitment on thepart of SM to remain current. At this point, I for one am skeptical thatthey'd be willing to take the time to implment the great solution youprovided.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 FeyrerSystem AdministratorFoodSpot.comchris@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:
splitting numbers in webDNA? (1997)
popups, netscape vs explorer (1997)
WebDNA 5.0 Questions (2003)
Command=Showcart? (2000)
customizing the color of user's pages (1997)
My first WebCat site (2000)
Performance: deafening silence (1999)
[if] (2003)
major search problem (1998)
BGcolor (1997)
hhtps to http and back? (2000)
webcat- multiple selection in input field (1997)
[OT] Linux -> Winderz (2005)
addlineitems within formvariable loop (1998)
Relevancy Rating (1998)
ListFiles (1998)
Nested tags count question (1997)
WebCat2final1 crashes (1997)
[WebDNA] fastcgi 7+ & [cart]? (2010)
Calendar (1997)