Hi Thorsten, On Tuesday, 2006-10-31 22:48:39 +0100, Thorsten Behrens wrote:
> > 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. > > how would a spec help (a community dev) in reaching such an agreement? Not the spec in reaching an agreement, but the understanding that as long as there is no agreement there is no spec (an agreement may as well serve as a spec), and no _successful_ implementation of a user's requirement possible. Btw, you cut out an important piece of what I wrote: >> 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. Which was meant as the essential statement of that paragraph. If nobody is going to read and understand all 42 comments, and new comments with own opinions are added to the issue, and the new comments turn out to either just repeat what already was agreed upon or repeat what was rejected, there is not much sense in following large parts of the issue anymore. What I was trying to point to is the fact that reading and editing a collaborative wiki page for specification is much easier than browsing through a lengthy issue and understanding only half of it or getting tired before reaching the end. A structured one-pager with pros and cons is much more helpful, and drawing some conclusion from it and turning that into a decision-making spec by just marking some of its statements as do's and don'ts shouldn't be that problem. > > 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. > > > I wouldn't say that we need this picture, in a sense that we need to > require it from everyone. I tried to split the things that are > essential for others to digest/evaluate/QA a contribution, This is where the picture I mentioned is aimed at. In a rough sense it just tells what happens if the user does this or that, the UI tools available, and what he can expect as the result of certain actions. > from the > ones that 'just' have the potential to make life easier/less wasteful > for a developer. Those should be suggestions, not requirements. Agreed. > > > - have UI specified by experts (user experience) > > > It naturally pays off to have a small group of wizards sign off UI and > strings, in terms of cohesiveness, terminology, and ease of use. But > it obviously doesn't scale up currently. That said, facing yet another bottleneck: if a method doesn't scale with the needs, don't adapt the needs, adapt the method instead. > I'd guess much of the aforementioned problems will be non-issues, once > there's a GUI editor available - because then, adapting UI quickly > (possibly by user experience), Ah, lovely idea, UserEx doesn't like a dialog's layout and shifts its elements around to meet gusto and edits strings to make them match the glossary and such :-) > > 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. > > > Aww, of course. I thought we already did that. :-/ Seems you weren't involved in any string changes lately ;-) > > 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? > > > Ours (the Sun devs/code owners). But I wouldn't see it as a burden > (most of the time), Well, I do, at least with the spec process we had in the past, which fortunately already is changing. I probably love doing specs as much as Michael does.. > more like a mediating/facilitating role. In the > best of all cases, patch contributor and QA/DOC just need to be > connected. No problem with that. > In other cases, more work might be necessary, but since the > patch gets thorough code review anyway, information about changed/new > behaviour should be a by-product. Still ok if my notes written down will be accepted as a spec at the end and I don't have to artificially press them into some form again to meet some template's need, except doing a well worded abstract that is used for the feature guide. More important: in a wiki it could be edited or completed by the contributor or whomever, which with the old spec repository (.sxw/.ods in cvs) was not possible, not even concurrent editing because of the binary checkin. > If UE has their say, admittedly, more work is necessary. But as > pointed out above, the root cause of that problem is IMO not fixable > with whatever spec process we come up with. Agreed. > > 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'm indifferent about that. Maybe I'm biased by the past template's > narrow scope (specialized towards UI features). I think this may change when we switch to wiki based specs, and more specification of behavior will get in. Eike -- 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 the [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]
