[Sugar-devel] Sugar UI Dictator

[Martin Dengler]

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
> proposal[1]

Your proposal seems like a good way to do it.  I propose another
decent way as an appendix[2].  I welcome someone else implementing
either.  I think both, however, require more administration than we're
liable to get :(.

I think the implicit, current situation is:

1. All patches have to satisfy any committer that notices...
2. unless overruled by the Design Team

And that's not too bad, given there are a large number of sugar
committers and not too many members of the Design Team and neither
group changes very often.

The bad part is that it was implicit, and that we could do better
(like what you proposed).

Martin

1. http://lists.sugarlabs.org/archive/sugar-devel/2010-November/028615.html

2. Proposal #2, Concerning UX patches:

0 - any patch is a UX patch if a committer says it is

1 - The UX patch acceptance criteria will be as follows:
1a - UX patches have to be accompanied by HIG change patches (in any
     reviewable form), or a statement as to why none is required
1b - UX patches with non-trivial HIG changes should be accompanied by
     appropriate supporting material (non-anecdotal user feedback, for
     example)

2 - accepting UX patches will be done by the following people:
2a - any committer can commit a UX patch as long as it complies with
     the criteria above
2b - any committer can revert a UX patch
2c - the Design Team will adjudicate any disagreements amongst
     committers

Issues:

a) my intent is that the main difference between Michael's proposal[1]
and mine be the degree of formality of the acceptance "committee".

b) social considerations will be used keep any disagreements to a
minimum; amicable differences of opinion may persist.

c) it is intentional that anyone who can commit code can affect the UX
as long as the design team isn't sufficiently angered: the bias is
towards people willing to do the work, as that selects for the
momentum and contributors that Sugar needs.

d) I haven't thought about this enough, but this will have to do.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20101110/0d6c03c6/attachment.pgp>