unity-design team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

Martin Owens wrote:
> Hello Mark,
>
> On Wed, 2009-10-21 at 11:09 +0100, Mark Shuttleworth wrote:
>   
>> First, we get much better collaboration and communication,
>>     
>
> Do we? The first thing I've noticed from this experimental opinionated
> stance is a tendency to alienate and frustrate people who want to
> collaborate.

Yes and no.

Sometimes folks actually want to push their own ideas, and think that's
collaboration. That's not going to work here, because we have a core
driver already.

There is lots to be done around that core, and this list is one way
people can participate in that.

>  There are people who will give up their personal visions
> for yours without lots of hard data, but most of those are called
> employees...
>   
Not really. Employees aren't serfs. But it's true that we have more
opportunity to reach a common understanding in areas where we have
higher-bandwidth interaction.

>> and much better testing, if everyone is looking at the same
>> experience.
>>     
>
> Testing and experience can be brought about by standardisation of
> configuration at testing time.
>   
The famous "many eyes" do their testing all day, every day, on the
system they are running. They don't generally setup and run default
configurations to test just for fun.


>> We found this with Ubuntu itself - we reduced the default application
>> install set to a single app for each major function
>>     
>
> The key here is 'distribution default'. I will congratulate you on the
> decision to prevent choice paralysis in normal users, insisting upon a
> single application per function at distribution time is the right
> choice. But this is development, this is upstream, that logic may not be
> relevant.

Ah, right, the old "WE are above the default, WE are smarter, WE can
have it any way we want". Sure you can. Just not here ;-)

>  I notice that you don't insist upon one application per
> function available in the repositories or launchpad PPAs.
>   
Of course not. Nor would I resist there being many branches of
notify-osd. But I will resist calls for "this should be an option".

I've done it before on this list, and will do it again, because it's a
common meme in open source. Creating an option is a way of avoiding
social tension - "we don't have to either agree or consent, we can just
create an option". It's a figleaf for a failure either to reach
consensus or to accept that someone may take a decision that has detractors.

Of course, that's not ALWAYS true. But it is generally the case, and in
this case it REALLY is the case.

>> One of the great failings of the community approach is that it
>> attracts folks who like to customise the environment to the point
>> where it is "perfect for them", at which point they stop caring about
>> the environment that the typical user sees.
>>     
>
> Why is the consumer grade user more important to design development than
> creative experimental people? This fight against the creative ecosystem
> can only be destructive.
Why is this a fight against creative, experimental people? There is
still lots of room for experimentation and creativity. But we will not
ship an obtuse, anything goes, highly configurable experience.

>  I believe it will drive people away, hurt
> upstreams, a number of side streams and limited sections of downstream.
>   
What does that mean exactly? I think you're mouthing off because you
don't like the idea of having to go with something you don't personally
like occasionally.

> But I have no data on that, that's just from my own principles of
> inclusion and experience in trying to do the hard job of bringing
> together conflicting ideas.
>   
If you have deep experience of that you'll understand what I mean when I
say you cannot always include everybody if you want a decisive and
exciting result. You can aim to include everyone if you are comfortable
taking a very long time to produce something that is hard to use and
ultimately not exciting.

>> In Ayatana, we'll take an opinionated stance, and we'll apply some
>> common principles to the design process,
>>     
>
> This principle isn't common,
This willingness to be decisive isn't common, no. By common principles I
meant that we will focus on specific areas of the experience, bring some
specific principles to bear, and live with the results.

>  it's something I haven't seen in any other
> projects, even the ones that I would aspire to with regards to design
> and vision.
>   
Such as?

> Can you tell me what the metrics that you'll be using to see the
> results?
>   
Whether or not non-computer-specialist people continue to embrace and
enjoy Ubuntu. And whether computer specialists continue to do the same.

>> I have no interest whatsoever in making it possible for anybody to
>> have any environment they want - we already have that.
>>     
>
> Hmm, I can't actually believe you would say that. It sounds so,
> authoritarian. To dictate what is in the best interest of the masses and
> removing the choices of those who aren't believers in the one true
> vision.
>
> It certainly doesn't sound like "I am because of my community", it
> sounds like "I am because of what Mark likes to see". Scary in a way.
>   
Take a good look at Ubuntu. We find the best people and empower them to
take hard decisions. That's how we got Upstart. It's how we got One CD.
It's how we got most of the really great things about the community,
including functional forums and IRC, and polite mailing lists.

Don't think that Ubuntu is built on equality of the producers. It is
not. It's built on empowering the best people to lead and take decisions.

You don't have to look very far to find projects with similar goals to
Ubuntu that don't have the guts or the willpower to take the same
approach. You can see for yourself the consequences - paralysis,
indecisiveness, slowness, complexity.

If you're reacting to the fact that right now I'm a driving force in
this, understand that the role will shift onto the shoulders of others
as that capability in Ubuntu and Canonical matures. It's been that way
with many things.

>> I'm interested in driving forwards to build a default out of the box
>> experience which is as good as we can make it for the new, consumer
>> user. 
>>     
>
> So am I, Fixing Bug #1 is top priority. End users (not just customers)
> are where my empathy has always been.
>   
Super.

> If representatives of Fedora or Debian were to come here and provide
> upstream patches to express the options they wanted to include in their
> distributions default configuration; Would the project accept them with
> the stated principle?
>   

In general, no. If the ideas they express are better, but the metrics we
can bring to bear (including the view of the people to whom the design
leadership has been given) then those patches can be included without
options, the default behaviour will be improved for all. If they just
create options for options sake, no. That creates complexity and cruft
in code. Go and look at the consequences of that, it's all around you.
Poor testing, poor quality, poor consistency.

Mark

Attachment: signature.asc
Description: OpenPGP digital signature