← Back to team overview

unity-design team mailing list archive

Re: Collaborative design dilemma

 

Given that fact that this is your mailing list, I appreciate the fact
that you would discuss this fact with us.  If the closed list is simply
a conduit for Canonical's internal developers to communicate about the
nitty gritty details of of architecture, then of course do it.  You'd be
silly not to.

If the purpose is big picture, the consider a possible alternative. Give
us some parameters and we will try to keep it in the lines. One of the
problems is to the best of my knowledge, there isn't a FAQ for this
group.  My understanding was this group existed for the community
discussion of development of the Desktop Experience (TM). 

I've never started a new thread, I've simply responded to ongoing
discussions. If any of my posts were out of line, I apologize.  I don't
think I have a competing vision for the desktop, but perhaps I poked at
a sore spot. Since there isn't a FAQ, expect some wandering.

However, even with a FAQ, this is the Internets.  The wheels fall off
occasionally.  It's part of the magnificent chaos of collaborative
design. Every single email doesn't need to be answered by Canonical
staff.  The others in the group tend to be effective at interaction and
line between Corporate and Community blur for most people.  Just make
sure people know just because you discuss it, doesn't make it happen. If
we are off topic, ignore us.  You will always have people that wont let
things drop. Silence is always an option.

As was said before, two lists are untenable. One would become the
defacto list, the other vestigial. 

Food for thought.  Ignore at your pleasure. 8)

Jim


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.

> Here's why.
> 
> I'm interested in the challenge of producing a free software desktop
> that's delightful to use, and convinced that good design has to be at
> the heart of that. I'm also certain that the design conversation and
> collaboration has to be open - at least about the pieces which are
> already in public play (in our case, for example, the Messaging
> Indicator, Notifications, and the Ubuntu Netbook Remix launcher
> (unity).
> 
> At Canonical, we've started growing a really good team to lead this
> work. There are now more than 10 folks at Canonical who's sole focus
> is design, art, and user experience, across the full range of
> Canonical products (web - Launchpad and Landscape, desktop - GNOME and
> UNR). To match that we have a team of developers that is implementing
> various bits and pieces that don't already exist, or don't already
> exist in the form that they need to in order to deliver the experience
> we want.
> 
> So I'm putting my money where my mouth is, in other words.
> 
> Figuring out how to shape the relationship between that company team,
> which works on public elements as well as things which are being
> designed for netbooks that aren't yet shipping and hence which have to
> be confidential, is challenging. The team is stretched, I don't think
> they can participate in a large public freeform mailing list
> discussion in the same leisurely way that many members of the
> community can do. That will create the impression that the Canonical
> team doesn't care, or isn't interested in the feedback.
> 
> The real challenge is that emails on this list can vary widely in how
> "hard they are to respond to". For example, an email on a specific
> design issue is easy to fit into a work day. There's a person who is
> responsible for taking the final decision on that piece, and they can
> participate in that thread and then communicate the decision.
> 
> Much harder is a broadbased thread like "high level goals" or "what is
> beautiful". I just don't see any way to have the full time team engage
> in long threads like that.
> 
> My current view is that we need a core team that meets in person
> fairly regularly and has a shared set of language and tools. That team
> needs to be open to participation from the community, but it also
> needs to have a shared set of values, so it frankly would not be open
> to folks who have a completely different vision of the future. That
> core team can collaborate with the goal of producing final
> specifications for Ubuntu. The team should all be at UDS, for example.
> It should not be a team that fights with itself - it needs to be made
> up of people who trust each other and work well together. And they
> should not have to defend every single decision against a flood from
> folks who are not part of the team.
> 
> That means that the design process would contain explicit separation
> between folks on that core team, and others who express interest in a
> more casual fashion, or who have not yet bought into the core design
> ideas and process of the core team.
> 
> I'm aware this proposal could result in outrage over barriers to
> participation. But I think it will be more effective if we try to
> build a core team that knows each other well and can establish norms
> and relationships.
> 
> Besides, I don't think effective design would come from purely
> freeform participation. At the moment, I have final signoff of
> specifications coming from the design team into Ubuntu. In due course,
> that responsibility will be assumed by someone in the Canonical design
> team. There is collaboration and consensus in many elements of the
> work, but to the extent that decisions are taken in that final signoff
> they are final and binding. And that will remain true even when
> someone else takes over from me.
> 
> Thoughts?
> Mark 
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp

Attachment: smime.p7s
Description: S/MIME cryptographic signature


References