unity-design team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

On Fri, 2009-10-16 at 10:52 +0100, Mark Shuttleworth wrote:
> I don't think we can succeed if we work on a list that is free for
> everyone to throw their ideas onto. I'm thinking that we need to
> create an invitation-only list (which is publicly archived) alongside
> this one.

I understand what you're trying to achieve, but I think an invite only
list is probably not the way to go.  Especially if the method for that
invite is based on invitation instead of governance.

When I look at this problem, I can't help but to notice that it's
similar to starting a new operating system and deciding who should be
able to upload the kernel.  I think the structures that have been used
there, and found to be successful, should be used again.

What I'm thinking are two things, we have a title that is "Ubuntu
Designer."  Similar to becoming a Ubuntu member where you have to put
your work for Ubuntu into the Wiki and go in front of a board to say
that you care about Ubuntu.  In the same way we could put design work
forward and show that they care about design, but also about design in
Ubuntu.

Secondly, to evaluate applications and to make the "tough choices" a
group that we could call the "Design Board" which would be similar to
the Technical Board, but for making design decisions.

Obviously both of these would have to be seeded by Canonical HR first,
as pretty much the Technical board and core-dev where starting out when
they were being developed.  But, long term the goal should be to have
them associated with an election by the designers working on Ubuntu.

I think that the disputes on the list could be largely eliminated by
developing a set of "Ubuntu Design Principles" that designs could be
evaluated against.  So when discussing notifications we could talk about
"Principle 42: Never force artificial time tables on users" and how
that'd change things.  I'd say that the design board should consider
that a living document and update it accordingly.

I agree with the problems.  I'm not sure that just a list solves them,
especially without a very transparent membership requirements.

		--Ted

Attachment: signature.asc
Description: This is a digitally signed message part