[Dextrose] Sugar UI Dictator

[Gary C Martin]

Hi Martin,

On 20 Nov 2010, at 09:32, Martin Dengler wrote:

> On Fri, Nov 12, 2010 at 12:06:56AM -0500, Michael Stone wrote:
>> Martin and I talked for bit this evening and I believe that I managed to
>> persuade him to support my [UI Dictator team] proposal.
> 
> I do, for the reasons mentioned in Michael's "key arguments".
> 
>> P.S. - Later [...] 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?
> 
> I think it is both act as maintainer and make UI-related decisions.
> It seems we're re-invented the Design Team.  I spoke with Gary Martin
> and Bernie and, despite having lost the logs of my conversation with
> Gary, my hazy recollection is that that they also came to this
> conclusion.
> 
> With that in mind, I think we should just have more people actively
> participate in the design team.  I'm interested, so have put my name
> down on http://wiki.sugarlabs.org/go/Design_Team/Contacts#Team_Members
> .  I hope anyone else interested in being active, will do the same.
> Michael Stone, Bernie Innocenti, I'm looking at you.
> 
> Gary, can you add / correct anything from our conversation?

Summary: A two prong attack.

  1) HIG cleanup and polishing effort (one ring to rule them all)
  2) Focus on keeping a core of HIG compliant quality activities to act as our ambassadors

Hope you don't mind me posting, here's the irc log for those that want to skim:

[03:45] mtd: garycmartin: I was wondering if you had any thoughts about the UI dictator proposal
[03:45] mtd: garycmartin: given you're one of the victims m_stone named
[03:45] garycmartin: mtd: yea... :)
[03:46] garycmartin: mtd: I see two main prongs of attack.
[03:46] garycmartin: mtd: HIG (one ring to rule them all)
[03:47] garycmartin: mtd: Quality activities (make sure we have a handful of excellent HIG compliant examples)
[03:48] mtd: garycmartin: ok, good to remember what we're after :)
[03:49] garycmartin: mtd: Unfortunately most ports or new contributors don't seem to either read the first, or look at any of the second. Many can't even provide a basic HIG compliant icon :-(
[03:50] garycmartin: mtd: as to how we get there...
[03:51] garycmartin: mtd: I've been threatening to edit the HIG, there's plenty of obviously dud history in there now that can go with close to zero discussion.
[03:52] garycmartin: mtd: I was thinking of initially striking thru the out of date text, but leaving it there for some weeks/months.
[03:53] mtd: garycmartin: cool
[03:53] mtd: garycmartin: I think a new HIG version makes plenty of sense
[03:53] mtd: garycmartin: and wow, you want to do it :)
[03:53] garycmartin: mtd: With perhaps a new text colour for any additions I make, again for a month or so to give those with an interest the time to scan through.
[03:54] mtd: garycmartin: cool
[03:55] garycmartin: mtd: I'm pretty fed up with pinging folks on the list and replying to random email. It never seems to end and often seems to go silent. Would be quicker just to point folks to the HIG.
[03:56] mtd: garycmartin: yeah, I don't think that'd be too contentious
[03:56] mtd: garycmartin: (to take that approach)
[03:56] garycmartin: mtd: As to landing specific patches, I'd have to go with "If it's not HIG compliant, it gets an instant NAK, with a pointer to the HIG".
[03:57] mtd: garycmartin: understood and agreed
[03:57] mtd: garycmartin: so when you're done, I have a few questions.  But please continue.
[03:59] garycmartin: mtd: The patcher can then request a HIG update if they feel strongly about their proposed HIG design. Argument, as per usual, one the dev list by interested parties. If there's no agreement, it must default to a NAK.
[04:00] garycmartin: (s/one/on/)
[04:01] mtd: garycmartin: sounds good
[04:01] garycmartin: mtd: Go on, fire some questions.
[04:03] mtd: garycmartin: two points to consider, more than questions: the actions you've set out imply, to me, that the committee / dictator is acting as the UI maintainer; is that intentional?
[04:03] mtd: garycmartin: second, it also seems to imply that it owns the HIG; intentional as well?
[04:04] mtd: garycmartin: one minor one is: for patch acceptance, do we require HIG update sometimes / always if the HIG is silent / ambiguous on something affected / influencing the patch?
[04:04] • mtd finishes.
[04:04] garycmartin: mtd: yes I didn't completely follow that end argument from Michael.
[04:06] mtd: garycmartin: do my questions make it clearer?  or shall I clarify?
[04:06] garycmartin: mtd: I don't think the HIG should often change, any edits should be minimal, but we do need a good parse through it just now to get back in sync. Obviously there are also some totally new areas such as touch support.
[04:08] garycmartin: mtd: HIG grey (or blank) area cases you mean?
[04:10] mtd: garycmartin: no, I think I understand (and agree that it shouldn't change much)...
[04:10] mtd: garycmartin: I was wondering about the UI-maintainer-ship of the committee
[04:11] garycmartin: mtd: for example I don't remember specific timings being documented by the HIG for mouse hover palette pop-ups, that discussion has burst into flame off and on for years now.
[04:12] mtd: garycmartin: yeah, and that could be useful to document as an implementation detail, I guess.  Perhaps there are (in an ideal world where we al have time) a few passes through the HIG: a) cruft-removal; b) gap-filling if obvious historical justifications exist; c) mark missing sections; and d) more, bigger changes.
[04:13] garycmartin: mtd: FWIW committee == Design Team in my mind, that's what it is there for, even though there is close to zero regular activity. I don't think changing the name, a new list of protocols, and re-naming some folks helps too much.
[04:14] mtd: garycmartin: ah ok, that answers a few questions all at once
[04:14] mtd: garycmartin: that seems a simpler solution
[04:15] garycmartin: mtd: +1 on your a, b, c, (and d == something like touch support)
[04:15] mtd: garycmartin: yup, exactly what I was trying to say
[04:16] mtd: garycmartin: ok so may I take a stab at characterising your position on the committee:
[04:16] garycmartin: mtd: Christian is still active when he has the time (I have the occasional IRC with him and private email traffic), Eben is about, but more rarely these days.
[04:16] mtd: garycmartin: basically the committee is really an attempt to work around the lack of active design team members, and as such, it would be better to just change the design team
[04:17] mtd: garycmartin: cool
[04:17] mtd: garycmartin: so perhaps I should say "add more members [to the design team]" rather than "change"
[04:17] mtd: garycmartin: is that your thinking?
[04:18] mtd: garycmartin: michael and I did conclude that's what we seemed to be edging toward
[04:18] • mtd tries to recall the conversation more precisely
[04:20] garycmartin: mtd: One reason the design team seems to have faded away is it's very annoying gong over and over arguments as each new 'doer' comes along. I try and stay out of threads unless it looks like something truly horrible is about to hit the fan.
[04:21] mtd: garycmartin: I hear and agree on both points
[04:21] garycmartin: mtd: Michael has suggested to me in the past I should just be more blunt as early as possible (paraphrasing), but so much seems to get half done and then dropped, having that design discussion early is very expensive.
[04:23] mtd: garycmartin: indeed - lazy evaluation is great for that half-baked stuff that never gets out of the oven
[04:24] mtd: garycmartin: I think the distinction between your conception and Michael's proposal is that his is less ambitious
[04:24] mtd: garycmartin: I have reviewed his and my conversation, and we explicitly discussed taking over the design team, and didn't come to a conclusion
[04:25] mtd: garycmartin: ...except to note that I was more interested in maintainer-ship (patch acceptance / not) and less about HIG updates.  I think it's all a continuum, but those are definitely two ends.
[04:25] garycmartin: mtd: design team -> "add more members" that seems to be the default cry of every team, and we're not moving very fast there :-(
[04:26] mtd: garycmartin: do you think anyone would object if I suggested you be added to the design team?
[04:26] mtd: garycmartin: I don't know who would
[04:26] garycmartin: mtd: I am in it already :-)
[04:26] mtd: garycmartin: ahaha excellent!
[04:26] mtd: garycmartin: yeah then I guess we don't need most of this discussion :)
[04:27] garycmartin: mtd: http://wiki.sugarlabs.org/go/Design_Team/Contacts
[04:27] garycmartin: mtd: I note you are not on it ;-)
[04:28] mtd: garycmartin: I guess people are just swamped, but if you NAK patches that get through the Quozl / gonzalo / mtd / other filter (and correct any incorrect NAKs), then I guess I think we've at least clarified the responsibilities in my mind...
[04:28] mtd: garycmartin: and I would think perhaps we could advance the UI committee discussion a bit.
[04:28] mtd: garycmartin: Heh I don't think I know enough about design to be on it :)
[04:29] mtd: garycmartin: so in my mind -- always in flux, but... -- the design team IS the "dictator" bernie asked about and you are active, so we have a design dictator...
[04:30] mtd: garycmartin: and unless you speak up we can assume the rest of us are acting in accordance with your dictatorial wishes.
[04:30] garycmartin: mtd: I don't like to 'NAK' without providing a good (as I can) argument, hopefully with suggestions as to the 'fix'. That takes a lot of time :-(
[04:30] mtd: garycmartin: in terms of patch acceptance, "doer" education, etc.
[04:30] mtd: garycmartin: I understand.
[04:30] mtd: garycmartin: that is a hard problem.
[04:31] mtd: garycmartin: I think in a pinch a NAK without explanation is better than no NAK, though.
[04:31] mtd: garycmartin: and I think there are quite enough of us that have seen you around enough to understand the "no, will explain later" as a response
[04:32] mtd: garycmartin: in fact I will be less equivocal
[04:32] mtd: garycmartin: please consider me an ardent supporter of the "NAK first, provide explanations later" crown
[04:32] mtd: garycmartin: as it at least keeps activity going
[04:33] garycmartin: mtd: I'd rather we got as many doer's following the HIG to the best of their good will, or avoiding UI changes where possible. Where UI change is not possible to avoid and does not comply with the HIG, emails to the devel list with [DESIGN] in their subject should be fired off.
[04:34] garycmartin: mtd: I see making the HIG as complete as possible the only way I'll ever get any free time to actually do any real coding work myself.
[04:34] mtd: garycmartin: I think we can work with that.  At some point you can get to sleep or whatever and I can attempt a summary and reply to Michael's latest mail.
[04:34] mtd: garycmartin: yup, understood.
[04:35] mtd: garycmartin: perhaps some people can make a HIG-FAQ with a bit less authoritativeness but more currency to aid doers and shift some burden from the design team.
[04:36] garycmartin: mtd: yes, a quick HIG summary page could be helpful.
[04:36] mtd: (by "currency" I mean "up-to-date-ness")
[04:37] mtd: (and "I lack a thesaurus")
[04:37] mtd: garycmartin: cool
[04:39] garycmartin: mtd: any thoughts on dealing with HIG versioning?
[04:41] garycmartin: mtd: we have things like the 0.84 and back old toolbars, vs new toolbars. Should the old frame/home design be removed, or archived?
[04:42] mtd: garycmartin: I support versioning :)
[04:42] mtd: garycmartin: the HIG, unqualified, should be useful for developers, I guess
[04:42] mtd: garycmartin: the old versions should be archived
[04:42] mtd: garycmartin: I thought of suggesting that but it's a lot of work
[04:43] mtd: s/that/versioning the HIG per sugar release/
[04:43] garycmartin: mtd: I worry about folks googling and getting old pages without realising it, but I like the idea of history as well (wiki history is not really much use)
[04:44] garycmartin: mtd: I guess just the usual large "depreciated" banners across the top of old pages.
[04:44] mtd: garycmartin: yeah - perhaps a banner across the top of the page could be used to highlight old pages or something (I am sure something can be done in wiki-land, but I don't know it)
[04:44] mtd: garycmartin: yup

FWIW: I'm thinking trying to version the HIG might be a step to far, though we could keep some old sections where it correctly describes some past Sugar release behaviour (clearly marking such paragraphs as history, perhaps with very brief summaries for the change).

Regards,
-Gary

> Michael, is there anything I've misunderstood/misremembered about your
> proposal?  Would you want the Design Team to adopt your "what does the
> committee do"[1] responsibilities? 
> 
> Martin
> 
> [1]  http://lists.sugarlabs.org/archive/sugar-devel/2010-November/028615.html
>