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 a good place. I of course could recommend Chris Lukasiak
to you, who happened to take the UX role in the Base team after our
previous UX expert left for other tasks.
Personally, I am immodest enough to offer my help in the Dev as well as
UX area, though I fear I haven't as much time to spend for the project
as I would like to have.
--Q4 [i-Team Agreement]:
--Do all i-Team members agree on Q1 - Q3?
Well, first I need these three people...
--What happens if I can't answer all questions mentioned above, with Yes?
--The consequence could be that your valuable work won't be integrated
--into OpenOffice.org.
So, at the moment I should better not start.... or should I?
You should.
I consider a specification a very good means to plan a feature, to stay
in contact with the stakeholders (which is very important, see above),
to ensure that all the time all of them see the same big picture ... I
do *not* consider a specification and end in itself, as I do not
consider the Qs an end in themselves - if you can reach what they (the
Qs, and on a higher level the spec itself) want to ensure by other
means, then Just Do It (TM).
Although it might
not be necessary to meet all these requirements as long as only the spec is
going to be written, it would be a good idea to involve at least a User
Experience member.
Yes.
Ciao
Frank
