Re[2]: Support suggestions - long (was politeness, et al)
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 25957
interpreted = N
texte = Bugzilla is open sourced, so it would not cost anything for PCS/SM to adopt it in that respect, but it may be costly to maintain. The real question is whether a $2500/license product requires or even can support such a complete/complicated system.See http://www.mozilla.org/bugs/source.html for information on using Bugzilla yourself. At first glance, it seems to be a set of Perl scripts as CGI programs. All of the data is stored in a local MySQL database. Any reasonably competent UNIX admin with Perl experience should be able to install everything and get it running. It is possible to run under WinNT, but I don't know that I would recommend it.John Peacock ____________________Reply Separator____________________ Subject: Re: Support suggestions - long (was politeness, et al) Author:
(WebCatalog Talk) Date: 1/7/00 8:36 AMInteresting, 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:
| |
- Re[2]: Support suggestions - long (was politeness, et al) (jpeacock@univpress.com 2000)
|
Bugzilla is open sourced, so it would not cost anything for PCS/SM to adopt it in that respect, but it may be costly to maintain. The real question is whether a $2500/license product requires or even can support such a complete/complicated system.See http://www.mozilla.org/bugs/source.html for information on using Bugzilla yourself. At first glance, it seems to be a set of Perl scripts as CGI programs. All of the data is stored in a local MySQL database. Any reasonably competent UNIX admin with Perl experience should be able to install everything and get it running. It is possible to run under WinNT, but I don't know that I would recommend it.John Peacock ____________________Reply Separator____________________ Subject: Re: Support suggestions - long (was politeness, et al) Author: (WebCatalog Talk) Date: 1/7/00 8:36 AMInteresting, 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
jpeacock@univpress.com
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:
AppleScript: Tell application:app location? (1998)
searching by date range help needed (1997)
[SHOWNEXT] Examples (1997)
PIXO support (1997)
Re:2nd WebCatalog2 Feature Request (1996)
Working HTML email (2001)
[WebDNA] group searching not working as expected. (2010)
RE: WebCat cannot handle compatible search parameters? (1997)
Re:E-Mailer (WebCatb15acgiMac) (1997)
WebCat2b15MacPlugin - [protect] (1997)
how to do multiple prices/item? (1998)
Directory Overload (1998)
Mystery File - Solved (2005)
Some Advise needed (1997)
writing checkboxes to a database (2000)
WC2.0 Memory Requirements (1997)
Country & Ship-to address & other fields ? (1997)
Nested [tags] (2001)
Calendar (1997)
Initiating NewCart (1997)