Hi Frank,
On Wed, 2006-10-18 at 12:35 +0200, Frank Schönheit wrote:
> In this case, Uwe would have told you that various documentation would
> need to be updated, to keep the product consistent
So - my experience is that the more people involved in a decision - the
less likely any decision is to be taken: consider the difficulty of
choosing a restaurant with 3 people vs. 10 people. "I don't like
Chinese", "I can't walk far", "I know this place ..."
Do you observe that phenomena too ? [ every week ? ]
Currently from my perspective we ( as a project ) don't suffer from too
many things happening at all quickly; indeed glacial movement is racing
past us, wrt. getting changes up-stream. Of course things are nice and
cosy inside Sun I'm sure - where there is some central-planning and
people can be persecuted in person through some chain of command.
Consequently, at the moment, I'm by instinct -hyper- reluctant to
consult anyone about anything if it can at all, possibly be avoided by
some means. For me consultation means a black hole of months of
unresponsiveness, and the need to go around begging yet more people to
actually do something. Perhaps you can persuade me otherwise, that by
consulting more people we'll get a genuinely better result, and not
endless delays ?
Let me show you why I feel this way, from a simple example I was
reading this morning: notice the consultation going on in this issue:
http://www.openoffice.org/issues/show_bug.cgi?id=56202
[snip]
------- Additional comments from nn Tue Apr 4 ... 2006 -------
Default keyboard shortcuts are administered by User Experience, so
I'm cc'ing MMP to allow him to comment.
..
[snip]
A (perhaps) reasonable request - I mean, we just want to add a
keybinding that doesn't exist, in 1 language, to be more compatible with
what people expect. It is now Oct 19th 2006 - and we're still waiting
for User Experience to comment. And - wait, let me see - who is to blame
here ? it is clearly going to be my fault for not throttling someone
earlier ? This of course, is one of the more recent issues, some are
rather older.
Otherwise, in principle - I'm well up for getting as many people
involved as possible; as long as they have the right attitude:
"wow, thanks for your work, let me help you get it included"
I know this is your attitude personally Frank, and I've enjoyed working
with you on several pieces of code; however all too often people's
attitude seems to be:
"I'm so busy I can't be bothered to reply to your mail/issue"
or "no - I'm too busy to handle this => I'll block it"
or "yes it's fine, but some step in the process wasn't done in
the correct order => reject"
> (The fact that the current help is ... sub-optimal doesn't mean
> we're allowed to make it worse, by out-dating it knowingly.)
As I say, of the ~million or so users that have been exposed to the
outdated help in this area, none I know of have noticed or cared enough
to actually file a bug. That suggests to me that my decision (in this
case) to let the help get out of sync was not altogether a bad one -
what's your take on this data point ? are you certain that help should
be updated synchronously ? A converse data point is that lots of people
were happy with the new Quick-starter and congratulated me
personally ;-) [ though Raul wrote a bug chunk of it in fact ]
> Other people - from QA - might have expressed interest to get their
> fingers on the CWS before it's integrated, to add the new feature to
> their existing tests.
Sounds good to me; another problem is, finding out who these people are
and how to them involved ? of course, I love to work with domain experts
that are responsive and helpful, and I'm happy to help inform QA on what
they need to test things.
> Yet other people could have told you that there in fact is an existing
> specification for the quickstarter, which claims that's a Windows-only
> feature.
I wonder if anyone has ever read it after it was written - perhaps we
can tell that from the web server logs. I wonder if it is still
accurate ? [ or are you suggesting all screenshots and string lists
duplicated in any specification must be updated for any relevant string
change ? ].
> Now also this specification is out-of-date (which makes
> specifications effectively useless, on the long run).
As you know, I think *almost* all specifications, particularly for
something so mind-blowingly simple (conceptually) as the quick-starter
are broadly a total waste of time; or to abuse your words are
"effectively useless" anyway :-) I for one, don't want to be writing the
transparently obvious down at great length repeatedly. It seems Sun
people have a different view.
> As you can see, the idea of involving different people with different
> competences (that's the idea behind an iTeam) *early* is not an end in
> itself - it's about delivering a self-contained, consistent product to
> our users, and about preventing trouble in other parts of this huge project.
At last count, we (at least) had a list of QA team members who could be
contacted to form an 'iTeam' in the wiki. Is there an equivalent list
for the other people ? i18n, User Experience, Help ? - that would be
helpful.
I find it hard to communicate how intensely frustrating the Sun
interaction is, but I just thought of an innovative way here, watch this
space.
Either way - there is a clear and simple way forwards here I think that
should please everyone. In the next CWS (gtkquickstart2) I will disable
the feature by default making it reliant on a configure option that will
not be turned on in Sun builds. Then if Sun wants to actually ship a
product with this feature they can do all this pointless specification /
iTeam stuff themselves [ if they can be bothered ]. Novell has paid
enough implementing the feature, testing it, shipping it ourselves,
filing bugs, creating CWS', committing, closing bugs, re-doing up-stream
builds on 2x platforms, re-testing it etc.
I hope that will satisfy your love of process,
Regards,
Michael.
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
