Re: [dba-dev] New Filter Dialog
Hi Karl, So I _could_ start...? Definitely. Of course the more people you involve, especially from UX the more chances the specified changes will ever become reality :) (And of course, the more people you involve, the more difficult it will become due to the lot of different opinions :) I guess I have to use the specification template for Writer. Matter of taste. Personally, I find writing specifications in the Wiki more difficult with regard to the involved work in actually writing, on the other hand, the Wiki has its advantages (the online version is always up-to-date, corrections/additions can easily be made by other parties, etc.). The Wiki template can be found at http://wiki.services.openoffice.org/wiki/Specification_Template (unfortunately not linked from http://wiki.services.openoffice.org/wiki/Specification). On [2] I found some other things that need to be done/checked before I start: In general, do not impose too much meaning into those requirements (but don't cite me on that :). (-- denotes a quote) --Q1 [Feature/Enhancement] --Does an unambiguously clear feature or enhancement request exists? Well, does one exist? I hope the description in [1] is enough to fullfill this request. If not, what has to be done? For this item, like for the others, the following holds: It is *one* possible mean to ensure a certain pre-requisite. There are other means, and case-depending, you might choose one of the others. (That's my personal interpretation, but it worked well in the past :) What this requirement wants to ensure is that all involved parties have the same understanding of the goal. In fact, this requirement is *very* important, and not fulfilling it is a main reason for specification failures. If you specify something which doesn't address the needs others have, this doesn't help at all. What I found extremely useful in the initiation phase of the feature is to hold a meeting with all stakeholders (however you define that), and to ensure that they all know and agree what the project is about. Luckily, I could do this in person often enough, for your purpose I would suggest an IRC meeting. So: gather the people which you want to work with on the feature, e.g. the ones which should give you feedback while the spec evolves, ideally also the ones who will later (probably) implement and QA the feature. Make sure you want the same thing. Make sure that if you say the current dialog sucks, they all do not only nod, but you find out *why* it sucks, to make it better. Else, you'll notice when you finished the spec that you all had different understandings of it sucks. Then go for it, and ignore Q1. (Such gatherings can be useful in various stages of the process, so don't think it's over after the initial kick-off meeting.) --Q2 [Concept]: --For changes requiring modifications in more than one application: Is --there product concept available, which is understandable to the --intended readership? I guess, this is irrelevant Yes. since only one application is concerned: Base. and also since Produce Concept Documents are an relict from early times ;) --Q3 [Project-Resources]: --Do you have a project team? An OpenOffice.org feature is always --being developed by an Implementation Team (i-Team). An i-Team consists --at least of two distinct persons: --* A developer (required) --* A QA representative (required) -- Ask for a QA representative in the d...@qa.openoffice.org mailing list. --* A User Experience member (required only if the feature or bug -- fix affects the user interface or the behavior of the application) This is my first problem. How do I get this i-team? I have to specify their names in the spec. I can ask for a QA representative as described, but where do I get a developer? And how do I get a User Experience member? Ask around :) preface: One thing you need to be aware of is that it is well possible that you write the perfect specification for a perfect feature, but nobody will be able to pick it up for development, for whatever reasons. Ideally, it won't happen this way, but nobody can guarantee that. If this doesn't scare you, go on ... Having said that ... ignore the developer for the moment. Since you do not know who will later on implement it, you cannot invite the implementor. Which doesn't mean that you cannot ask (in d...@dba - oh, this is where we currently are in :) core developers to join, if you want. They are often able to give hints about cool features in the spec which are hard (up to impossible) to implement in the current OOo infrastructure, and you certainly want to know those to raise your spec's chances of being implemented ... Similar things hold for QA. Having more user ex members (more because I assume that you have a certain user ex affinity, else you wouldn't offer to write a spec) is always a good thing. Again, asking is what gives you answers/volunteers. disc...@ux is
Re: [dba-dev] New Filter Dialog
No more to say ;-) Thanks. - oj On 03/01/09 23:02, Frank Schönheit - Sun Microsystems Germany wrote: Hi Karl, So I _could_ start...? Definitely. Of course the more people you involve, especially from UX the more chances the specified changes will ever become reality :) (And of course, the more people you involve, the more difficult it will become due to the lot of different opinions :) I guess I have to use the specification template for Writer. Matter of taste. Personally, I find writing specifications in the Wiki more difficult with regard to the involved work in actually writing, on the other hand, the Wiki has its advantages (the online version is always up-to-date, corrections/additions can easily be made by other parties, etc.). The Wiki template can be found at http://wiki.services.openoffice.org/wiki/Specification_Template (unfortunately not linked from http://wiki.services.openoffice.org/wiki/Specification). On [2] I found some other things that need to be done/checked before I start: In general, do not impose too much meaning into those requirements (but don't cite me on that :). (-- denotes a quote) --Q1 [Feature/Enhancement] --Does an unambiguously clear feature or enhancement request exists? Well, does one exist? I hope the description in [1] is enough to fullfill this request. If not, what has to be done? For this item, like for the others, the following holds: It is *one* possible mean to ensure a certain pre-requisite. There are other means, and case-depending, you might choose one of the others. (That's my personal interpretation, but it worked well in the past :) What this requirement wants to ensure is that all involved parties have the same understanding of the goal. In fact, this requirement is *very* important, and not fulfilling it is a main reason for specification failures. If you specify something which doesn't address the needs others have, this doesn't help at all. What I found extremely useful in the initiation phase of the feature is to hold a meeting with all stakeholders (however you define that), and to ensure that they all know and agree what the project is about. Luckily, I could do this in person often enough, for your purpose I would suggest an IRC meeting. So: gather the people which you want to work with on the feature, e.g. the ones which should give you feedback while the spec evolves, ideally also the ones who will later (probably) implement and QA the feature. Make sure you want the same thing. Make sure that if you say the current dialog sucks, they all do not only nod, but you find out *why* it sucks, to make it better. Else, you'll notice when you finished the spec that you all had different understandings of it sucks. Then go for it, and ignore Q1. (Such gatherings can be useful in various stages of the process, so don't think it's over after the initial kick-off meeting.) --Q2 [Concept]: --For changes requiring modifications in more than one application: Is --there product concept available, which is understandable to the --intended readership? I guess, this is irrelevant Yes. since only one application is concerned: Base. and also since Produce Concept Documents are an relict from early times ;) --Q3 [Project-Resources]: --Do you have a project team? An OpenOffice.org feature is always --being developed by an Implementation Team (i-Team). An i-Team consists --at least of two distinct persons: --* A developer (required) --* A QA representative (required) -- Ask for a QA representative in the d...@qa.openoffice.org mailing list. --* A User Experience member (required only if the feature or bug -- fix affects the user interface or the behavior of the application) This is my first problem. How do I get this i-team? I have to specify their names in the spec. I can ask for a QA representative as described, but where do I get a developer? And how do I get a User Experience member? Ask around :) preface: One thing you need to be aware of is that it is well possible that you write the perfect specification for a perfect feature, but nobody will be able to pick it up for development, for whatever reasons. Ideally, it won't happen this way, but nobody can guarantee that. If this doesn't scare you, go on ... Having said that ... ignore the developer for the moment. Since you do not know who will later on implement it, you cannot invite the implementor. Which doesn't mean that you cannot ask (in d...@dba - oh, this is where we currently are in :) core developers to join, if you want. They are often able to give hints about cool features in the spec which are hard (up to impossible) to implement in the current OOo infrastructure, and you certainly want to know those to raise your spec's chances of being implemented ... Similar things hold for QA. Having more user ex members (more because I assume that you have a certain user ex
