How does the Netscape team figure into this? For instance, as part of the next big release, they're actively working on a quicksearch for the thread pane, and there is a little debate going on about whether the toolbar should get a grippy. (bug 103734). Would they have to take this to newsgroups before a decision is made? If they went ahead with it, would mozilla the organization "reject" a new feature? What is their stance?
Gervase Markham wrote: > This is the third draft of a document which attempts to define how > changes can be made to the UI of Mozilla. > > Feedback is welcome in netscape.public.mozilla.ui. > > Gerv > > <snip> > Mozilla UI Design and Implementation Process - Draft 3 > ------------------------------------------------------ > > This document defines how significant changes to the Mozilla UI are > made. It is not supposed to cover trivial things, like fixing typos or > mis-sized dialogs. > > This process is based on specs. A spec defines exactly what a piece of > UI should look like and act like. It provides a way of defining whether > UI is correct or not - "does it meet the spec?" In general, specs should > be for an individual dialog or window; in the larger cases such as the > main Navigator UI, they may be for a subset, such as "Navigator window > toolbars". The central repository of UI specs will be located at > http://www.mozilla.org/projects/ui/specs > If there is no spec for a piece of UI in the repository, the spec is "as > it appears and works at the moment." > > This process is overseen by a person who in the following document will > be referred to as the Module Owner. If there is an appointed Mozilla UI > Module Owner for the relevant piece of UI, then this role is filled by > that person. If not, then the role is filled by the peers in that module > in cooperation. The job of this person is to achieve closure by pulling > together ideas from discussion to produce the spec that will be > implemented. They are expected to act according to the guidelines set > out in the Module Owners document, and to take input from the Module > Owner of the code which implements the UI. Module Owners are also > expected to coordinate with each other to attempt to ensure as much > cross-app consistency as possible in the product. There will certainly > be cases where Module Owners make changes with a less formal design > process, but significant changes should happen as follows. > > Anyone, including the Module Owner, planning/proposing a significant > change should file a bug in the User Interface: Design Feedback > component noting the UI proposal (e.g., "Proposed [X] Implementation"), > and leave the Default Owner and QA Contact as is. The person proposing > the change should also post the proposed specs at the central repository > as soon as practical. The posted spec should be clearly marked as "Draft > - not to be implemented." They should then make an announcement with the > following headers: > > Newsgroup: netscape.public.mozilla.ui > Newsgroup: netscape.public.mozilla.<area> > Newsgroup: netscape.public.mozilla.ui.announce > Followup-To: netscape.public.mozilla.ui > Followup-To: netscape.public.mozilla.<area> > > where <area> is e.g. browser or mail-news or editor. (The ui.announce > newsgroup will be created.) > > Discussion will then ensue. After a period, the Module Owner will call a > halt, and the spec proposer will revise the spec based on feedback, and > the expressed wish of the Module Owner. Specifically, the Module Owner > may call a halt to the discussion if: > - discussion has died out, or > - no new points have been made in the past few days, or > - a reasonable period of time has elapsed. > The Module Owner needs to sign off on the spec for it to be considered > final. The Module Owner is requested to articulate the reasoning behind > their decision on particularly controversial issues. > > The final spec produced must be immediately implementable - that is to > say, it should not contain UI for features which are not yet written, > unless either those features are due to be implemented at the same time > by the person implementing the UI, or there is a strong expectation that > they will be finished by the time the UI is implemented. If anyone > wishes to post an "ideal" UI spec which does not meet this restriction > to the repository, they may do so, but it should be clearly marked as > "Ideal - not to be implemented." > > This spec is then considered canonical, and should be marked as > "Current", until further changes are proposed and it goes through this > process again. From this point on there will be no significant further > review of the content of the UI, and the Module Owner is free to ignore > further comment. This does not restrict the Module Owner's right to > change the specs, but Module Owners are requested not to change the > spec, particularly on issues which have proved controversial, without a > further discussion period. > > This spec can then be implemented by anyone. Implementors are warned > that, if they begin before a spec is finalised, they may have to make > changes. The existence of patches should have no effect on the UI > decisions taken. The patch will go through code review and code > super-review in the normal way. There will be a requirement for UI > review (uir) from one of the peers in that module - this review is > limited to answering the question "Does it match the spec?" and so > should not be burdensome. uir= can be given by the reviewer or > super-reviewer if they are a Peer for the relevant UI module. If they > feel strongly that a change should be made which was not discussed in > the discussion period, they should consult the Module Owner. > > There will be hard cases, where a group believes a suggested change is a > bad idea and should not be implemented by anyone, and others strongly > disagree. In such cases we expect open and honest communications without > personal attacks. This means actually listening and considering > alternative points of view. As in all things, [EMAIL PROTECTED] are the > ultimate arbitrators. >
