[Sugar-devel] Sugar UI Dictator
michael at laptop.org
Fri Nov 12 00:06:56 EST 2010
On Wed, 10 Nov 2010 at 09:16:41 +0000, Martin Dengler wrote:
>On Tue, Nov 09, 2010 at 12:27:18PM -0500, Michael Stone wrote:
>> On Tue, 9 Nov 2010 at 03:12:41 +0000, Martin Dengler wrote:
>> >On Mon, Nov 08, 2010 at 07:49:19PM -0500, Bernie Innocenti wrote:
>> >>[UX design might be better] if we agreed to delegate all design
>> >>decisions to one clever dictator
>> >Great idea.
>> >[if noone steps forward], perhaps we could just agree
>> >on some group of people who will be the dictators, and not revisit
>> >that for a while.
>> Agreeing on small group of people seems easy to arrange. Here's a strawman
> Your proposal seems like a good way to do it. I propose another decent way as
> an appendix. I welcome someone else implementing either.
Martin and I talked for bit this evening and I believe that I managed to
persuade him to support my proposal.
Here were the key arguments:
1. We're currently very vulnerable to "diffusion of responsibility".
Concentrating responsibility in three specific people will help to address
2. We don't really have a dispute resolution mechanism other than "drop it".
The Oversight Board is ideally positioned to help resolve disputes
generated by its committees' decisions and procedures.
3. It's not okay to block patches on feedback or decisions from an absent
As with "diffusion of responsibility", being explicit about the time frame
on which decisions will be made will help prevent these patches from
4. We need to be able to work smoothly with OLPC if and when they succeed in
hiring a Sugar UX Designer .
Being able to elect said designer to a seat on a previously established
design committee seems like a potentially good way to involve this person
in our decision-making while still preserving fairness, transparency, and
appropriate continuity with the past.
P.S. - Later, after finding our common ground, we spoke further about the
issues that we each hoped the committee might be able to address. In the course
of the conversation, we discovered a confusion about the mandate of the
proposed committee; to wit:
Is the main purpose of the committee to act as a UI Maintainer (e.g., by
deciding which UI-related patches to merge) or is the main purpose of the
committee to make UI-related decisions on an as-requested basis?
More information about the Sugar-devel