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
> 

_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Reply via email to