Hi Thorsten,
On Tuesday, 2006-10-31 12:06:28 +0100, Thorsten Behrens wrote:
> But the difference is that there's no request from high-above to
> implement a certain feature, and no dedicated time in user experience
> to roll out a detailed UI spec beforehand.
Specs aren't only about UI, they're also about behavior of a feature.
Behavior of a feature, if not obvious, is something that must be agreed
upon. We do have examples of started development, patches were sent in,
but there wasn't even an agreement on how the feature should really
work, discussion in the issue continues, more patches attached, but
still no agreement. At the end this leads to nowhere because you won't
get someone from UserEx to even read the issue anymore, because the 42
comments to the issue are not digestible for anyone not involved from
the beginning.
One more +1 for a wiki for specification.
> People just start coding. So the example of car production might suit
> the way Sun-internal features are developed,
Nah, comparing software development with car manufacturing always has
a bit ... well ... some taste of helplessness..
> but it doesn't fit the
> community. Community specs are nearly always after-the-fact
> documentation of the implemented feature, thus, the argument that
> specs save rework costs just doesn't apply here (simply - because all
> the work has been done already, when the spec is written).
>
> I don't question the need for _some_ documentation - QA and especially
> help authors need a way to test and describe the things that newly
> enter the product. But I do question the very strict requirements the
> spec process puts on community contributions, and I second Michael's
> statement that most of those requirements (in their current
> installment of the spec process) don't add much value to the
> production line (mind that - I'm talking about community contributions
> here).
While I completely agree on the entire paragraph above,
> In the end, specs serve multiple purposes Sun-internally:
>
> - have a feature well thought-out beforehand
> - have UI specified by experts (user experience)
> - have strings reviewed by experts
> - have feature documentation for QA
> - have feature documentation for help authors
> - ...etc. I've probably forgot a few more items.
>
> The first three items should not be required for non-Sun
> contributions, because they just don't affect us
I don't agree on this statement. It affects us, and with "us" I'm
referring the entire OOo project, not only Sun. We don't need the "Big
Design Up Front" (BDUF) picture, especially not in its waterfall model
sense, but maybe "Enough Design Up Front" (EDUF), as was also noted by
some Agile/XP enthusiasts [1][2][3] when Joel (on Software) came up with
his "love BDUF" [4]. We do need _some_ picture of a feature. A picture
we may as well add to, correct, recolour, overpaint, or even tear apart
after some cycles of evolution. So I'd like to replace your point you
say we don't need to
> - have a feature well thought-out beforehand
with
- have a feature _enough_ thought-out beforehand
Again, a wiki may be a perfect place for this.
On to the next:
> - have UI specified by experts (user experience)
This affects us. UI has to be consistent, functional, and should guide
users like most users expect. This is what UserEx should have an eye on.
Much of software evaluation (in organizations, governments, companies,
by journalists, ...) happens on the UI level. If that has quirks it will
give us OOo bad reputation. I don't say we need UserEx for each and
every single check box, but sometimes we may even need them to say ok to
where the checkbox is placed.
> - have strings reviewed by experts
Yes and no. It is vital for a good UI to name identical things
identical, and different things different throughout the entire product.
You need at least to check with a glossary now and then, or sometimes
need a hint to phrase something different. UserEx can provide those
hints.
However, far more important than a string review, IMHO, would be to drop
German as a developer provided second source localization. Let's get rid
of that. There's no sense in it other than most Hamburg engineers being
native German speakers. Two major drawbacks with the German source
localization are:
1. non-Hamburg contributors most certainly can't provide it.
2. If they can manage somehow, it doesn't necessarily mean it's a good
localization, bable fish and the like..
- This localization will stick until issues are submitted. AFAIK
there is no following localization process.
> - if a CWS needs
> rework because of them, it's the burden of the community dev. But they
> should be free to choose their way, and not be pressed into a mold,
> that has been designed for a Sun-employed OOo developer.
Seconded, but "if a CWS needs rework because of them" effectively means
the spec/UI/string things may be done any time, maybe even after the CWS
was set ready-for-QA the first time, and somehow it's up to the
community developer working on a CWS whether she likes to rework
everything because UE/QA wasn't satisfied with. A bit dissatisfactory
for the developer.. why not involve UE/QA earlier?
Anyway, all this, work done in a CWS by a community developer, leaves
out the frequent situation where a patch arrives for some feature or
enhancement attached to an issue and eagerly awaits to get applied,
which for smaller enhancements most times happens in a CWS a Sun
developer has open anyway, and only for larger features a CWS on its own
is created. Whose burden is it then to provide necessary spec and
involve UE/QA/DOC?
> And we've some (minimal)
> documentation requirements, to enable other people to do their
> work. But the specifics, or even the outer form, of those
> documentation, should IMO not be specified (no pun intended ;-)) in
> minute detail - if QA or help authors miss something, they can simply
> ask, can't they? I mean, that's what currently happens all the time,
> even with the spec process in place.
Btw, if this model ought to work, module helpcontent2 has to be added to
a CWS, as you never know when a CWS will be ready and to which release
it will be integrated. The same may be true for QA automation tools of
module qadevOOo.
> > Now I am at a company and learned, that re-work costs are really costs
> > money and is very annoying for the users. Therefore I am now a fan of
> > the processes which are taught at study.
> >
> Absolutely correct. And I'd recommend every community developer
> starting to implement a major feature to spend some time on planning &
> discussion, even doing UI mock-ups. But we shouldn't _force_ them to
> do that, and we shouldn't use that as an all-or-nothing argument for
> the spec process. We should request what we really need
> (documentation), and leave all the rest unspecified. ;-)
Ok, but let's clearly state then that a CWS may sit there and wait for
ages if the necessary docs aren't provided. And had to be resynced and
rebuilt if more then xx milestones old before QA would even take a look
at it.
Btw I think a template does ease things a lot, be it as a document or
a wiki template, because it guides the spec author and she doesn't have
to pull some prosa out of her head.
I think much of the hurdle are communication (habit) problems instead of
a specification (template) problem. If we agree that we need some
spec/doc and need to collaborate, then it doesn't matter if one or the
other part doesn't answer in a timely manner in the issue, in the spec,
or in the wiki.
Eike
[1]
http://blogs.codehaus.org/people/tirsen/archives/001159_joel_is_misunderstanding_xp_and_bduf.html
[2] http://haacked.com/archive/2005/08/18/9536.aspx
[3] http://www.google.com/search?q=Joel+%22Big+Design+Up+Front%22
[4] http://www.joelonsoftware.com/articles/AardvarkSpec.html
--
OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't send personal mail to this [EMAIL PROTECTED] account, which I use
for
mailing lists only and don't read from outside Sun. Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
