As we build towards to the next [Ubuntu Developer Summit](https://uds.ubuntu.com/) in a few weeks, we have been getting our blueprints and plans in place to have a comprehensive set of discussions at the event. Unfortunately I won’t be there, fortunately due to an impending bundle of baby joy that will be entering my life, but I will be [remotely participating](https://uds.ubuntu.com/community/remote-participation/). Be sure to join us there, there is no excuse, people. 🙂

As part of these plans I have been having some wonderful discussions with *Ivo Weevers* who is the head of the Canonical design team and who reports directly to Mark Shuttleworth. Ivo is passionate about helping the design team at Canonical and the community to work closely together, and we have been discussing what problems we need to solve, and how to resolve them. In the past there have been concerns in the community that it is difficult for our community to actively participate in design and Ivo and I are keen to solve these challenges.

There are many topics to be discussed and we are currently fleshing out the schedule for UDS, but I am keen to solicit feedback about one particular piece of this puzzle.

Thankfully we are not trying to figure out the puzzle of opening one of these instruments of frustration.

As many of you will know, Ubuntu is a *meritocracy*; when people do great work, they have more influence over the project. As an example, our developers who work hard and become approved core-dev or MOTU contributors have more influence over our development operations than those who have not put in this level of development work. Now, before the haters start hatin’, I agree that Ubuntu is not a *perfect* meritocracy in that some Canonical staff members have direct influence over Ubuntu in a way that the community are unable to contribute. Examples of this include our infrastructure and systems teams, and to a degree this also includes the design team.

In a world in which everyone has a strong opinion about design, I believe that part of solving this challenge is that we need a means in which we can highlight the great designers from not-so-good designers. To be clear, this does not necessarily mean designers who agree with the Canonical design team, but instead designers who are collaborative, talented, contribute significant and sustained work, and bring their expertise forward to improve Ubuntu…the very same criteria we use to judge other areas of expertise in the project.

In the development world we have a pretty well defined way of assessing the cream of the development crop while still providing an opportunity for *everyone* to be able to ascend and aspire to that level of quality. We have methods of contributing that can build up a body of work that can then be reviewed and direct upload rights can be granted when the quality requirements are met. To do this we have the following:

1. A clear definition of things that prospective developers can do.
2. A simple means in which non-uploaders can contribute their work.
3. Criteria that we can use to assess the quality of this body of work (e.g. technical quality, effectively following our guidelines and principles, providing a *significant and sustained* body of work etc).

I was chatting to Ivo about this and we would like to define the same three equivalent attributes for the design part of Ubuntu. Namely, we need to be able to point to things that people can do, have a means of reviewing this work effectively, and importantly, define criteria of *what makes a great designer*. I would propose that we apply these assessments to create an equivalent to core-dev in the development team but for designers. This way everyone can contribute more widely, but we can have a team of reliable, effective, community contributors that works closely with the Canonical design team and a clear means in which anyone can learn how to gain the skills to join this team.

I wanted to open up this discussion to the community to get your feedback and then we can review the feedback and discuss it at UDS and then start formulating a plan for the 13.04 cycle. In putting forward your suggestions, please bear in mind that we need to make the solution light-weight for everyone involved, both new contributors and those who will be reviewing the work of others.