mozilla.org staff would like to implement some changes to make the UI
Design process smoother. We plan to evaluate how this is working in a
few months, say the May-June timeframe, and look for further
improvements. Of course, we'll reevaluate a lot sooner if we have an
unexpected crisis.
1. Matthew Thomas has offered to be the owner for the Bugzilla component
"User Interface: Design Feedback." The current owner supports this and
we'd like to accept. Zack Lipton has agreed to be the Default QA
contact. There may be a slight delay while Matthew gets the necessary
computer access, but Zack can get started right away.
2. We know that Netscape will be doing a significant amount of UI design
work, and has asked that a Mozilla representative attend Netscape UI
meetings and represent the views of the Mozilla community. We plan to
accept, and recommend that Ben Goodger be this representative. Ben's
combination of implementation expertise, design focus and understanding
of Mozilla community concerns should prove invaluable.
3. Anyone planning/proposing a significant change would 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. We expect the bulk of comments about the proposal to
end up in this bug, although people may choose to file a new bug against
the designer for some specific aspect of the proposal. The person
proposing the change should also post the proposed specs at
www.mozilla.org <http://www.mozilla.org> as soon as practical, and make
an announcement in the m.ui newsgroup. There will certainly be cases
where Module Owners make changes without a formal design process, but
significant changes should receive a design-based review.
4. We hope the UI: DF Owner can synthesize the comments into a cohesive
critique or alternative proposal. This will undoubtedly involve triaging
and prioritizing requests, since this seems to be a recurring thing in
software development, not to mention life in general.
5. We anticipate that the bug created under item 3 will remain owned by
the UI: DF Owner as the central feedback forum. The UI: DF Owner may
choose to create bugs reflecting the work in item 4 and assign them to
the developer of the proposal. As with other bugs, the designer may
choose whether or not to accept the bug. Accepted bugs should have
relevant comments and target milestones just like any other bug. When a
bug is not accepted, a comment should be added explaining the rationale.
Such a bug remains in the "New" state, indicating that no one is working
on it; someone else might assign the bug to him or herself and work on it.
6. 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. If Netscape is involved, we
expect that the UI: DF Owner will work with Ben to develop the most
compelling alternative possible and discuss it in Netscape's UI design
meetings. We expect determined efforts to resolve these issues through
overlays or other technical means if agreement is not possible.
7. The Module Owners determine whether they will accept the UI design or
not. We anticipate some rejections, especially if the design involves
the addition or subtraction of features, as a design for an "ideal" user
interface might do.
Follow-up to m.ui or [EMAIL PROTECTED] please.
Mitchell
