unity-design team mailing list archive

[Sense Hofstede <qense@xxxxxxxxxx>]

On 8 June 2010 07:57, Mark Shuttleworth <mark@xxxxxxxxxx> wrote:
> On 07/06/10 21:37, Tyler Brainerd wrote:
>> I would love nothing more then for all the mockups and design
>> specifications from the last year and a half were fully implemented,
>> instead of covered up by newer ideas.
>
> I don't think the new ideas are "covering up", they are completing the
> overall vision of Unity, so that the "map" is clear. We want to address:
> notifications, indicators, window management, launcher, places,
> settings, menus. That defines "Ayatana", and we want to get those pieces
> nailed. We have many OTHER things we'd love to do as well, but getting
> that framework defined and implemented is the priority.
There is simply too much to do. :)

>
> The team is small, and we're focused on the things that provide shape to
> the environment. We would appreciate any help, both in polishing the
> core pieces and in assisting applications to take advantage of the
> infrastructure that's provided.
>
> As for quality, I think the DX team will attest to the fact that we've
> set a higher bar for these items than people have traditionally
> associated with open source. I'm glad you can see the potential! The
> team is united in wanting to put out tight, high quality pieces. As a
> result, everything we produce has high quality test suites, to reduce
> regressions in future as the code evolves.
>
> On your critique: Notify-OSD is not done, but it's broadly there. The
> API's are basically stable, and we would gladly accept patches that
> bring it into full compliance with the specification. We would not
> accept patches that overcomplicate it in order to add features that are
> not in the specification.

The fact that the community could do these things by themselves is a
valid point indeed. I agree with it. However, the fact that you would
love to see patches from the community is not very clear. If I feel
the community correctly I think that many people seem to assume that
most of the work is done or will be done by your team. If it is in the
specification than, so they think, it will be done by Canonical
anyway, we can just sit back and wait for the features to land.

It is my opinion that Ayatana should be made more community developer
friendly. This means two things:
1. Make it clear to the community that and how they can contribute
code (or artwork and documentation?) to the Ayatana projects. This
could de done via a separate home for the Ayatana project (e.g. a
slick <http://ayatana.ubuntu.com/> page that tells people what Ayatana
is, what it means for users and what it means for developers. The page
then could link to information for people who want to use Ayatana in
their applications and another page explaining how to contribute to
Ayatana.
2. Make it clear to the community what Canonical is working on and
what Canonical plans to work on in the near future. This would assure
users they can work on feature X because Canonical is busy with
feature Y and won't have the resources to work on X this cycle. Also,
I would advise to make sure code is available (together with the
roadmap and maybe a list detailing who's working on what) to allow
community developers to start working along with the DX team.

You could summarise the two points above in one word: communication. I
know that especially the design team has made progress on this, but it
remains something all in-company teams should pay attention to. I know
it is not always easy to do it properly without an angry mob burning
you down and I know it takes a lot of time, but it is tremendously
important to do it anyway. (I'm not saying that you're doing a bad job
at communicating, I'm just saying that -- like always -- there is some
room for improvement.)

>
> Mark

Cheers,
-- 
Sense Hofstede
[ˈsɛn.sə ˈɦɔf.steː.də]