[Sugar-devel] Sugar UI Dictator
martin at martindengler.com
Wed Nov 10 04:16:41 EST 2010
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. 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).
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
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
a) my intent is that the main difference between Michael's proposal
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
Size: 190 bytes
Desc: not available
More information about the Sugar-devel