Hi Frank,
Sorry to spam you with yet another huge E-mail, this is quite an
effective technique known as "argument by exhaustion" ;-)
On Wed, 2006-10-25 at 09:48 +0200, Frank Schönheit wrote:
> I agree with you that those hurdles experienced by contributors are a
> big reason for not attracting more developers.
Good 'oh :-) and of course, so do we - and various people are trying to
fix them: trying to make the BuildBot work well is a prime example. What
I want is to be able to test CWS builds easily on Win32 - since that's a
problematic platform for me (and virtually all Free software
developers), it requires proprietary tooling to get anywhere, and well -
it's of course critical that it's not broken. Contrary to popular belief
I don't like to break the build / code :-)
> All I can seriously recomment is: keep fighting. Both for people from
> "outside Sun" as well as "inside Sun" :).
Thanks for the encouragement :-)
> I will do myself, as I did in the past, since I heartly believe that we
> cannot throw all full-blown processes at a newcomer who does a small
> fix/feature.
Right - and of course, I'm to some extent preaching to the choir here,
you've done some great work in this area in the past.
> This doesn't mean those processes/requirements are unnecessary or
> stupid, it just means that we should allow people to grow and learn, and
> not do everything right and complete in the first step.
Ah - in itself it doesn't mean the processes/requirements are *not*
unnecessary or stupid either ;-) Simply because you can think of 10 good
reasons for a process, doesn't mean that that there are not many other
more weighty reasons for not using it.
> > Well - my attitude here is rather different :-) in the time that it
> > took to create the CWS, commit the code, go through QA etc. I had in
> > parallel done a number of other improvements / fixes, and subsequently
...
> Well, and that's a fundamental misunderstanding on your side, sorry.
>
> That's explicitly *not* how OpenOffice.org works. The whole idea of
> child workspaces is closely coupled to the idea of having a stable
> master build. In ideal, we would be able to ship every master build (in
> reality, that's not the case, but we're much better than some years ago).
Interesting. I don't know how you square that with the state the code
is in, and (even) some of the things that people commit to it [ even
with specs ;-].
> That's an explicitly stated goal of the OpenOffice.org project: We don't
> break the master, we finish implementations in a child workspace, until
> they're really finished.
It's a worthy goal, ultimately though - no matter how much QA you put
into something, you won't find some bugs until it is deployed. And I was
aware of -no- bugs in the feature when it went it ( I am of course
now ;-) only some areas for future work: so what does 'finished' mean ?
It's interesting & instructive to head to LXR & search for TODO:
http://go-oo.org/lxr/search?string=TODO
'handle error', 'error handling', 'Check return value', 'introduce
error handling', 'still needed?' ... ...
> Other projects have other means for ensuring quality. For instance,
> Mozilla has a *very* rigid code review process. OpenOffice.org's mean
> for ensuring quality is the "finish it on a child workspace" policy.
> There's no room here for "put it in and let it evolve".
I would be amazed if we actually managed to get any non-trivial piece
of code through to HEAD that had no defects found in it later.
> You might want to question this idea and policy, but please not by
> silently undermining it.
Pah ;-) as I said, it was a less feature-full implementation, not a
(known) buggy one. And I think it's a legitimate decision.
> However, what I really *really* like about this process is the exchange
> of ideas and arguments. In my experience, sitting down (or meeting in
> IRC) with a small (!) number of people having experience with and/or
> interest in a particular feature is invaluable. You always gain insights
> you wouldn't have had alone. And finally, this means you deliver a
> better feature.
I wholeheartedly agree with the above. -Clearly- it is important to
talk to people skilled in the area of artwork, HCI, etc. etc. and to
some extent the more advice you can get the better. However - if you
hand out veto's to everyone, and then each communication round-trip
takes even days, life is not good.
I think the problem here is that the specification process also tries
to make a rigid mould into which to pour basic team activity &
interactions. The book I'm currently reading on building good teams
(Peopleware) tends to emphasise the stifling nature of methodology, and
homogoneity - and encourages diversity. ie. If your team happens to
communicate best by semaphore, and works only between 2am and 5am -
then, if they do great work, perhaps it's worth accommodating them
without feeling threatened :-)
If indeed, it was possible to discuss design interactively on IRC, with
a lag of minutes rather than hours, with lots of relevant stakeholders,
life would be rather better.
*Indeed* - you may have noticed me banging on about getting people on
IRC, so they can be consulted wrt. design decisions *before* doing their
development for -oh- only almost since I got involved with the
project :-)
> So, I still think that "put it in quickly and disable it in Sun builds"
> is the wrong way to go. Especially since this effectively means a fork,
> in the long run.
You seem resigned to Sun not putting in the effort to include the
feature themselves [ ie. writing the spec. ;-] - don't be so
fatalistic ;-). Instead - Sun will notice that customers want the
feature and that "everyone else" has it, and enable it when the
crazy-long-haired-experimentation is done [ and hence it is of a higher
quality ].
> If 10 percent of the code are not used in default builds provided at
> www.openoffice.org, than that's a (distro-specific) fork, not more.
It depends how many distros you get to turn it on. Arguably the distro
specific piece is the Sun distro :-)
> (I did mention that "Use systray quickstarter" makes me expect
> that when I check it, the QS is started immediately, didn't I? There's
> room for improvement from a user experience point of view, that's why
> iTeams are recommended to contain a user-experience-trained person.)
Good grief - so, the existing stock string in the Sun builds (on my XP
machine) is pretty terrible, however - since you think the existing,
shipping *Win32* quick-starter is 'finished' (and after-all it does have
a tiny mention in a specification) let's look at it:
+ "Load OpenOffice.org During System Start-Up"
1. this far and away the ugliest string I've seen in a
popup of this type: cf. attached screenshot.
+ it bloats the menu to an incredible width, all
other items are < 1/2 the length
+ aesthetically - this is rather unpleasing
+ the capitalisation is unfortunate, as you pointed out
2. the string is basically inaccurate
+ for me, this gets started on login,
+ -perhaps- if this was a single user machine,
it might get started "during system start-up"
Of course - fixing this is the matter of changing 1 string and
committing to HEAD right ? [ i18n will asynchronously notice the new
string & translate it ] ;-) but no; wait - I have to:
+ create a CWS (5 minutes)
+ commit the string change (20 secs)
+ find the specification (1 minute)
+ find where it lives in CVS (~N minutes)
+ check that out
+ update the spec.
+ take a new screenshot
+ translate the string to German (Babelfish?)
+ re-validate the change with User Experience, and i18n
+ N month delay.
+ commit the spec.
+ fiddle with EIS
+ build on 2 platforms
+ find a QA person
+ get them to download the spec.
+ ...
This is a -very- heavy process for fixing 1 string, that (I hope) we
can all agree is broken. So - the net result is, small changes don't get
done - and we have all these mini eye-sores, user-interaction rough
edges and pain-points lying all over the place - and they simply don't
get fixed. Of course, it's easy to laugh off 1 long string, but there
are a number of other nice examples catalogued in IZ of a similar
nature.
Is this sort of polish important ? If you read about user interface
design eg. Joel:
http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html
(and yes, I don't agree with Joel on everything), there are some really
interesting things; indeed - should be mandatory reading for S/W
engineers doing UI work I think:
[snip]
"One day, thinking about this problem, I noticed that one of the
bathtubs-with-wheels had pretty lousy wheels that wouldn't turn well.
Sometimes this bathtub did not go where I pushed it, and bumped into
things. This was a small frustration. Sometimes, as I was pulling the
chain to winch up the bathtub, I scraped myself -- just a little bit --
on a splinter of metal on the chain. Another small frustration.
Sometimes, as I ran with an empty bathtub to catch a dough emission
about to fly out of the mixer, I slipped on a little bit of oil on the
floor. Not enough to fall, mind you, just a tiny, small frustration.
And I started to learn that the days when I was happiest were the days
with lots of small successes and few small frustrations.
[/snip]
Anyhow - I'd recommend reading it, if you havn't already - particularly
the bit about "Learned Helpnessness".
> What I would like to see is...
And I broadly concur with your goals, indeed the "Just do it" thing was
rather funny :-)
Thanks Frank,
Michael.
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
