[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse.org-planning-council] Improving Project UIs for Ganymede
|
Mike,
So it would seem that when we signed up at
http://wiki.eclipse.org/Ganymede
we signed a blank check. :-P That should probably have been made more
clear, but I suppose that's okay since if the document itself is subject
to change after sign up, everyone is naturally free to renege on their end
of the agreement to follow a changing set rules (to the detriment of all
others who are downstream).
In any case, if you review the existing Ganymede rules, and those from the
past from Europa, they are focused on proper release engineering
principles, which sets a fairly low bar. What's being proposed now---and I
applaud that effort---is to take additional steps beyond that to touch on
consumability. Nevertheless, I feel compelled to point out that this
breaks our individual project planning processes if the end result is that
the planned for features in our individual development plans need to change
in unforeseen ways some time in the coming two months. So I will continue
to encourage the planning council to make requirements that impact project
development plans be should dos and not must dos. I will commit on a best
effort basis to conform to whatever should do and must do rules we
collectively decide are in the best interests of Eclipse as a whole.
I think we all want to make Eclipse even better so let's rely on good will
instead of coercion to achieve that goal.
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 969)
"Mike
Milinkovich"
<mike.milinkovich To
@eclipse.org> Ed Merks/Toronto/IBM@IBMCA,
"'eclipse.org-planning-council'"
09/26/2007 09:33 <eclipse.org-planning-council@eclip
AM se.org>
cc
<ui-best-practices-working-group@ec
Please respond to lipse.org>
<mike.milinkovich Subject
@eclipse.org> RE: [eclipse.org-planning-council]
Improving Project UIs for Ganymede
Ed,
I do not and can not disagree with anything you've said here. I thought
long
and hard about pushing on this. But the simple fact of the matter is that
we
have to do this for the good of Eclipse. We've talked and talked about what
to do about improving the UI fit and finish for the release train. This is
a
relatively small but concrete step that we can take. It is time to actually
*do* something.
And, as Bjorn pointed out, to our knowledge the list for Ganymede is still
TBD.
> -----Original Message-----
> From: Ed Merks [mailto:merks@xxxxxxxxxx]
> Sent: Wednesday, September 26, 2007 7:42 AM
> To: mike.milinkovich@xxxxxxxxxxx; eclipse.org-planning-council
> Cc: eclipse.org-planning-council@xxxxxxxxxxx; eclipse.org-planning-
> council-bounces@xxxxxxxxxxx; ui-best-practices-working-
> group@xxxxxxxxxxx
> Subject: Re: [eclipse.org-planning-council] Improving Project UIs for
> Ganymede
>
> Mike,
>
> Keep in mind that groups who have already signed up under the existing
> set
> of must dos did so with the basic and reasonable assumption that the
> set of
> must dos itself was fixed for Ganymede. So while downgrading
> requirements
> seems okay and certainly has happened in the past, upgrading the set of
> requirements for an already established agreement, particularly the
> must
> dos, requires the consent of all parties involved. So to my thinking,
> it's
> already past the time to add must do requirements for the current
> cycle.
> We should settle for should dos for the current cycle given the poor
> timing. It also seems to me that for the planning council to impose a
> set
> of requirements, it should be in a position to review those
> requirements
> first rather than put in place a requirement to conform to a
> yet-to-be-established check list. That would definitely be putting
> the
> cart before the horse.
>
> So while I agree that this is an extremely important issue and that
> taking
> action is a good thing, the timing is very poor. Out of respect for
> the
> committer community, it's best that the board not be seen to be
> operating
> on a schedule that's out of step with the development cycle that drives
> the
> committers. Plans have already been made by many groups, and what you
> propose is a change of plans. I believe that many groups will be more
> than
> happy to cooperate with these guidelines so a focus on encouraging
> cooperation rather than on forcing cooperation is far less likely to be
> met
> with a backlash. I can assure you my team and I will do the best we
> can
> to conform not only to the must dos but also to the should dos.
>
>
> Ed Merks/Toronto/IBM@IBMCA
> mailto: merks@xxxxxxxxxx
> 905-413-3265 (t/l 969)
>
>
>
>
>
> "Mike
> Milinkovich"
> <mike.milinkovich
> To
> @eclipse.org> <eclipse.org-planning-
> council@eclip
> Sent by: se.org>,
> eclipse.org-plann <ui-best-practices-working-
> group@ec
> ing-council-bounc lipse.org>
> es@xxxxxxxxxxx
> cc
>
>
> Subject
> 09/26/2007 12:02 [eclipse.org-planning-council]
> AM Improving Project UIs for
> Ganymede
>
>
> Please respond to
> mike.milinkovich@
> eclipse.org;
> Please respond to
> "eclipse.org-plan
> ning-council"
> <eclipse.org-plan
> ning-council@ecli
> pse.org>
>
>
>
>
>
>
> The EMO would like to suggest the following course of action for the
> Ganymede release with respect to user interface issues. I believe Bjorn
> will be adding this to the agenda of the Planning Council meeting at
> EclipseWorld.
>
> Background and Motivation
>
> · The Eclipse Board of Directors has added ??encourage
> improved usability and out-of-box experience in the projects?? as
> a
> strategic goal for 2008.
> · Everyone agrees that we want to improve the UI ?fit and
> finish? for the projects in the release train.
> · The current UI Guidelines document in draft is a large
> document. It is over 80 pages of suggestions, guidelines, etc.
> · There is no consensus that this ?UI Guidelines?
> document
> will be updated in time to be effective for Ganymede.
> · What does appear to be possible for Ganymede would be
> the
> ?...strong application of a small set of rules.?
> o The group has already created a draft list of the ?top
> ten
> dos? and the ?top ten don?ts?
> · There does appear to be a consensus that the UI WG can
> help
> projects if they bring their UI to the WG for review.
>
> Action Items
>
> To make progress for Ganymede, the following action items will be
> required
> by November 30th from the UI BP WG and the Planning Council:
>
> · UI Best Practice Working Group
> o The UI BP WG must finalize its ?top-XX list of dos? and
> a
> ?top-YY list of don?ts? (the ?UI Checklists?) by November
> 30th
> § Note that this can change in the future, but we
> need a
> frozen list for the Ganymede release cycle.
> o The UI BP WG will schedule reviews with all of the
> Ganymede
> projects during Q1 and Q2 ?08.
> § This scheduling will be prioritized by the 0, +1,
> +2
> grouping of the projects, i.e., they will review the
> 0
> projects first, then the +1s, then the +2s, etc.
> · The Planning Council will need to pass the following
> rules
> for inclusion in Ganymede projects.
> o Ganymede projects *must* comply with these ?UI
> Checklists?.
> o Ganymede projects *should* attempt to follow the draft
> UI
> guidelines wherever possible.
> o Ganymede projects *must* undergo a UI review with the
> UI
> Working Group and demonstrate compliance with the UI
> Checklists
> to the satisfaction of the WG.
> § UI WG concurrence with this compliance will be a
> Ganymede Release Review check item
>
>
>
>
> Mike Milinkovich
> Executive Director
> Eclipse Foundation, Inc.
> Office: +1.613.224.9461 x228
> Mobile: +1.613.220.3223
> mike.milinkovich@xxxxxxxxxxx
>
> blog: http://milinkovich.blogspot.com
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
