Eike Rathke <[EMAIL PROTECTED]> writes: > 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. > Hi Eike,
how would a spec help (a community dev) in reaching such an agreement? > > 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. > 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, from the ones that 'just' have the potential to make life easier/less wasteful for a developer. Those should be suggestions, not requirements. > 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. > Hm - I think this really depends a lot on how much UI is involved, whether there's prior art (either inside or outside OOo), and how much code is tied to the actual UI. Having explicit UI guidelines/design rules would most probably allow the average developer to correctly place a checkbox (in as much as control placement will ever be 'correct' - I've seen UI experts change their mind about such things in a relatively short timeframe). 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. 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), and even after-the-fact (like help authoring) is possible. > 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. :-/ > 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), more like a mediating/facilitating role. In the best of all cases, patch contributor and QA/DOC just need to be connected. 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. 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. > 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 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. > On this, I wholeheartedly agree. Cheers, -- Thorsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
