Thorsten Ziehm <[EMAIL PROTECTED]> writes: > Thorsten responding to Kohei: > > An example you want to design a new car. One important thing are the > tires. You said the development team you need a tire for your new car. > In you mind you know all details you need at the tires - height, width, > rim, how many bots etc. Without writing this into a specification, the > other team do not know, what you need and where it is good for. > > The specification template is should a support to do not forget > something in a dialog. And there are many things you can forget, when > you have to work platform independent and language independent. > I think the basic misunderstanding between our two camps (Sun people vs. OOo volunteers) is the fact that the typical workflow is simply radically different.
There's typically no such thing as formal upfront design for the normal community developer, it's just that people have their personal issues with OOo, and start fixing them in their private time. Like Kohei did with the missing calc solver. So, in the end, a volunteer dev pulls a feature out of her pockets that adds some amount of value to OOo. The code might have issues, the functionality might be incomplete, and the UI might not conform to some guidelines (BTW, I'd really like to have a written-down list of those UI requirements - in the Wiki or as an easily-digestible PDF with a prominent link). But that's why we have patch review, and CWSs, where we can polish that. And it's basically no difference in how Sun-internal features are developed - those usually have several cycles of implementation/testing/review, too. 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. People just start coding. So the example of car production might suit the way Sun-internal features are developed, 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). 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 - 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. The remaining two (+N) items naturally need to be done in some way or another, but my experience there is that every contributor just loves to talk (and blog) about his feature - thus, gently directing that enthusiasm into the right channels (wiki comes to mind) should really be a non-issue. In the end, I'm all for changes that encourage people to spend their spare time on OOo. We've checks and balances in place that will prevent accidental breakage on the master. 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. > 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. ;-) Just my 2 cents, -- Thorsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
