See attachment. What I want in particular is a list of keywords that should be used to better identify a bug report or RFE. Some of these that you may be familiar with are "RFE," "DUPEME," "[META]," etc. There are also some general terms such as "window" and "click" that pop up everywhere. Sometimes they are insignificant, but sometimes they are, and ensuring that only the significant matches show up in bug searches is essential to smooth develpment experience. I do not know how this can be solved. I also know this will be difficult. However, that it is difficult to solve does not excuse us from not doing it (to paraphrase somebody in a document.all Bugzilla bug comment).
I have prepared a quality plan for this initiative. It is not complete yet, but it demonstrates what good documentation looks like. btw, the list of key words would be on a level-three document. Minh Truong wrote: > I'll be glad to help, but I'm kinda new to bugzilla. I request that > people search for the bug when posting to my page, but most people don't > follow it. They either don't know what bugzilla is or they are too lazy. > I have to go bug hunting myself. For most bugs, I search for duplicates > first, that way it leads me to the original RFE. I find this more > convenient and quicker. Yes, I must admit, I filed some duplicate bugs > myself. > > I chose to document RFE because I think they are easiest to do. I don't > know how you would document more severe bugs since they keep popping up > and changing. You probably need the content to be dynamically generated. > RFE are stable and are neglected by the developers, but they get asked > a lot. Also, most of them have solutions availiable. > That's the difficult part. Usually it is easier to resolve a bug as duplicate than to resolve it as invalid or to confirm it as an unique bug :| I guess the best way to confirm if a bug is unique is producing a unique testcase. For the bugs that are reproducable only occassionally, what we could do is assemble a group of testers and test the bug exhaustively. We can than confirm if a bug is only an anonymity or a real bug. For RFEs, all I really wanna do is resolve them as BLOAT (should this be ever implemented) :pTitle: DevSupport Quality Plan: Pest Control 2002
DevSupport Quality Plan: Better Bug Support Initiative 2002 (L1)
0 Introduction (Non-normative) ficiton, but please make it come true
This document provides a framework of a yet un-named initiative to better manage user feedbacks from both Mozilla end users and Mozilla developers.
The needs for such an initiative is conceived out of the recognition that the sheer amount of feedbacks Mozilla developers receive hinder their ability to properly respond to feedbacks and to efficiently develop Mozilla. The responsibility that many Mozilla contributors feel they have to communicate with interested parties has created stress and to a certain extent has discouraged both developers and end users.
Over time, Mozilla contributors have developed their own techniques in dealing with feedbacks. However, such techniques have been poorly communicated, thus creating communication gaps between those who understand the languages used and those who do not. These techniques are also not always applied inconsistantly, thus slowing down communication.
Many of the communication techniques Mozilla developers use have great potential and, if used consistantly and appropriately, could alleviate much of the communication problems. Some, however, are quite controversial and sometimes cause more problems than they solve. There may also be communication problems that existing techniques do not address.
One objective of this initiative is, therefore, to provide a public forum in which all communication techniques can be collected in one place and discussed, refined, tested, documented, and published to the general public. The end product will be a set of style manuals and guidelines that a majority of interested developers agree to use. It is hoped that an unified language will facilitate Mozilla development and encourage more people to participate in it.
The begining work of this initiative grows out of the netscape.mozilla.public.documentation newsgroup. When this initiative began, the newsgroup was in disarray due to lack of coordination, documentation, public interests, and initiative. A second objective of this initiative, therefore, is to provide a working, initiative-driven model that demonstrates efficient coordinations and thorough, consistant documentation.
The initiative will be carried out in accordance to a minimum set of principles, procedures, and guidelines. These were first publicly discussed in the netscape.mozilla.public.documentation newsgroup and put into effect by popular consents. These "rules" are spelt out in a set of documents. The documents are grouped into three levels in term of scopes; they are:
- level one document: quality plan (this document) that spells out the quality objective, principles, and general requirements that governs all initiative activities, documents, and records;
- level two documents: procedures and specifications that specify requirements for particular areas in order to achieve the quality objective; and
- level three documents: instructions and guidelines that provide detailed and usable information for conforming the quality requirements.
0.1 About DevSupport
DevSupport (Developer Support) is a team of volunteers created to provide supports to Mozilla developers, including documentation writers, programmers, QA personels, third-party component developers, and beta testers. The objective of DevSupport is to provide a friendly and efficient environment in which developers of all levels of experties can contribute freely and in a focused mannor. Its works include, but not limit to:
- orientate, train, and encourage new contributors so they can get involved quickly, and
- filtering comments from end users and testers and redirecting them to the appropriate personels.
DevSupport is an independent team; it does not work under any Mozilla.org directive, nor does it obtain any "official" status from Mozilla.org. More information on DevSupport can be found in its Web site.
0.2 About this Document
This document is maintained by Daniel Wang (alias dwx). The contents of this document are subject to the Netscape Public License. Due credits of this document are to Daniel Wang (editing), Alice (technical consultant), Bob (formating), Carol (writing), and the following contributors for their comments: Alicia, Bobby, and Caroline.
1 Abstract
This section is non-normative.
2 Qaulity Objective
This section is normative.
The objective of this plan is to create and apply a self-consistant supporting system of communicating, handling, and documenting public feedbacks in existing communication channels to facilitate developers and developer supports in responding to public feedbacks and in Mozilla development.
3 Requirements
This section specifies a list of minimum general requirements that must be
conformed in order to achieve the quality objective. Requirement statements are numbered and
emphasized. This document does not specify how these requirements
should be met; the specifics of meeting these requirements are laid out in the documents
listed in the document catalogue.
