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