In article <[EMAIL PROTECTED]>, "german" <[EMAIL PROTECTED]>
wrote:
> Thanks for taking the time to write feedback.
>
> Braden McDaniel wrote:
>
>> In article <[EMAIL PROTECTED]>, "German Bauer"
>> <[EMAIL PROTECTED]> wrote:
>>
>>
>>> After talking to many folks inside and outside Mozilla, some of us got
>>> together to discuss ways of how to make the Mozilla User Experience
>>> Design Process more efficient, more open and more engaging. I have
>>> collected these thoughts and wrote them up as a proposal.
>>>
>>> The proposal is posted at http://www.mozilla.org/projects/ui/process/
>>> This is a rough draft, but if we can agree on the basic principles, I
>>> am
>>> ready to do what I can to help implement this.
>>>
>>> I would love to hear feedback, please post it to the
>>> netscape.public.mozilla.ui newsgroup, so that all interested folks can
>>> benefit. Thanks
>>
>>
>> It's nice to see this getting discussed, but it's apparent that we're a
>> long way from where we need to be.
>>
>> "Meetings are called as needed and are open to the UI lead from the
>> Mozilla community. The UI lead is responsible for bringing Mozilla
>> specific issues to the table."
>>
>> How nice of Netscape to allow a mozilla.org representative into the
>> meetings where it decides what Mozilla will look like.
>
> I am sorry you felt that way. I am seeing the Mozilla community as one
> body of UI-interested parties, but they may be one or more commercial
> companies that also build off Mozilla.
Several previous threads on .ui point away from the conclusion that the
Mozilla volunteer community and Netscape necessarily share goals for the
Mozilla UI. If other commercial entities get into this mix, the division
is likely to be more profound as branding strategies conflict. Your
proposal acknowledges this, yet still seems positioned in the interest of
a single commercial contributor.
> Right now this is Netscape, but
> there will be more in the future. By Mozilla UI lead I weas merely
> suggesting somebody that represents the path of UI that leads to Mozilla
> 1.0 which is a separate thing than a commercial 'derived' product. ( See
> doc.)
But this seems inverted. Shouldn't this be a mozilla.org meeting with
invitations to UI representatives from commercial contributors? If
mozilla.org is to attract commercial contributors other than Netscape,
these meetings need to be on more neutral ground and sound more like
mozilla.org meetings than Netscape meetings.
>> "The final decision on a particular design is made by group consensus."
>>
>> The document does not address what happens when there's a failure to
>> reach consensus. In that case, resolution should be in the hands of
>> [EMAIL PROTECTED]
> In that case one possibility the module decides whether its worth
> branching the UI . In my opinion there does not have to be one UI all
> the time as may have very different needs.
Branching is *always* a possibility, so this goes without saying. But
mozilla.org must always maintain the trunk--it is clients of the
codebase that have the opportunity to branch. I am sure that the drivers
would take the possibility of a branch into account when resolving a
contentious issue. Regardless of how many UIs are available, some
singular course of action will need to be decided for the mozilla.org
codebase--even if that course of action comes down to simply deciding
what something will default to.
>> "We currently have commercial builds as well as Mozilla builds, both
>> serve different goals and a different customer sets."
>>
>> "We" have commercial builds???
> See above I was merely referring to these as two types of 'strategies'
> or
> 'end products'. Right now there is 2: Netscape on a 6.x time table and
> Mozilla on their 0.x to 1.0 timetable. Both serve different time tables
> and needs. In the future there will other companies/products derived
> from the base Mozilla UI. If you have a better way of expressing this,
> I'd love to hear about it.
The needs of commercial contributors must certainly be balanced against
the mozilla.org timeline. However, mozilla.org should not be expected to
be privy to unreleased information regarding commercial development
timelines. To that end, it should remain largely oblivious.
Representatives from commercial contributors can, of course, express their
needs and the intended direction of their contributions. However, they
should be subject to mozilla.org's design--not the other way around.
>> German, why is this document posted on the mozilla.org Web site? This
>> is a Netscape document about *Netscape's* process. If it aims to be a
>> proposal for mozilla.org process, I think it needs to be rethought and
>> rewritten from the mozilla.org viewpoint.
> I am open to your suggestions. Let me know what portions you feel could
> be rewrittent to better represent mozilla as a whole.
I won't pretend to be able to speak for "mozilla as a whole". Anything I
say here should be construed as nothing more than my opinion based on
what I think mozilla.org is and what I think it ought to be. I think
mozilla.org should be able to provide neutral ground for contributors
from various commercial entities and the volunteer sector. As it stands,
your proposal would not provide this. Well, here are some concrete
suggestions:
* A.2: Why wouldn't this person be the module owner?
* B:
* Make meetings open to anyone via call in.
* These meetings should only be about Mozilla issues, and
vendor-specific concerns should be addressed in that context. Thus
the text, "The UI lead is responsible for bringing Mozilla
specific issues to the table," is unnecessary.
* C: I've already covered this: explicitly put the final decision in the
hands of [EMAIL PROTECTED]
* D: This part is good. It could be complemented by explicit mention of
the kind of information a UI spec should include.
* E: When using "we" to mean the Mozilla community in general, avoid
using it in a way that it might be confused to refer to mozilla.org.
This document should speak in the voice of mozilla.org, as it aims to
define a mozilla.org process.
* And last, but certainly not least, take "Netscape" out of the page's
title. Overlap between Netscape and mozilla.org process is Netscape's
concern, not mozilla.org's.
Braden
