Hi Cor,
On 10/25/06, Cor Nouws <[EMAIL PROTECTED]> wrote:
Hi David, *,
David Fraser wrote:
[...]
> 3) The spec process is apparently working well for those inside Sun,
> less well for those outside. If there were an easier route for those
> less involved in development to produce specs it could be run
> concurrently as an alternate mechanism (possibly with a final step of
> converting to the required template format, that could be automated)
> [...]
I happened to work with the specification template recently.[1]
I didn't find that too difficult. Indeed, I was not unlucky like the
posters on the list, encountering problems with the macro's. And I won't
say the it is perfect. But other aspects of realising a new feature,
give me much more problems than the spec-template.
The spec template is just one aspect of the whole picture here. :-)
The problem with the current specification process from my own
experience and observation is that, it puts the wrong focus on the
purpose that the project is intended to serve.
In the ideal world, a specification is written to clearly define what
a proposed feature is going to do, how it is going to work so that all
involved parties (documentation, marketing, QA and development) can
agree on how it is to be implemented before the actual coding starts.
If it works as designed, it saves grief and unpleasant surprises from
everyone, people involved from all different departments can schedule
their work accordingly, and at the end of the day, everybody is happy.
In a not-so-ideal world, things don't always go as planned.
Requirements grow organically over the development life cycle of that
feature, but the spec document may not always get updated. Once you
have the first prototype, everybody's focus goes to that prototype and
he or she makes his/her feedback based on that prototype, and based on
that feedback, the developer continues to work on the implementation,
demos it, gets further feedback, and it goes on until it reaches its
final state.
Ideally, the developer should also be responsible for updating the
spec document to ensure that it keeps up with the requirement change
over the development cycle. But such work is tedious, and it is
easily neglected.
Besides it being quite tedious, it is not clear at all (to my eye) how
this large number of specification documents[1] are being used in the
OpenOffice.org project as a whole, or people actually read them. I'd
be glad to be educated in this area, and eager to learn how they are
being used in actuality.
I can give you my experience with writing a spec. I have written this
specification[2] 2 years ago for a small feature I wrote for Calc.
After I uploaded this document, the first feedback I received was
(beside the very first encouraging and extensive feedback from
Niklas[4]) a year later from one user who just happened to come across
my spec document. He made a suggestion to change one aspect of how
the algorithm works because he believed it was an error, but that
happens to be a bug in the spec itself, because the code I wrote
already correctly implemented it. To this day, these are the only
feedbacks I received. The feature is still not yet integrated due to
another issue, but I won't get into there.
Back to the current spec template. I was probably too unfortunate to
experience the problem with the embedded basic code (I still don't
know how it worked for you, though), but posting a message on the
[EMAIL PROTECTED] mailing list obviously does not help because no one seems to
be on that mailing list, or no one reads the mails. To me, that
project looks stalled.
Unfortunately, writing a spec is a requirement for a feature that
requires a UI change, such as the feature I'm trying to get
integrated[3]. So, getting no response whatsoever means that, this
feature has to wait until either 1) someone be kind enough to give me
help figuring out what the problem is, 2) I have to go through all the
Basic code myself and figure out how to fix it (there is quite a bit
of code to go through), or 3) integrate it but disable it in the
default build, to avoid UI change (no UI, no spec).
My opinion is simply, why make the template this complex? In my view,
what's important is the content that goes into the specification
document, so I don't see the point of making it too unnecessarily
fancy (and not work under certain conditions). If the feature
involves no UI change, or simple enough to be described in a sentence
or two, giving an overview of the feature in a plain text file should
suffice. If it needs a screenshot or two, use Wiki or a simple Writer
document. If the author is more comfortable with HTML, use that
instead. Enforcing the format of a content when it is not very
critical puts unnecessary burden on the contributor's shoulder. Being
flexible here would make a lot of folks happier.
Writing a spec alone is already boring. So, please don't make it even
more boring. ;-)
Of course, if the spec requirement is lifted, that's even better. :-D
Ok. This opinion of mine is worth 20 JPY. :-)
Kohei
[1] http://specs.openoffice.org/
[2] http://specs.openoffice.org/calc/ease-of-use/natural_sort_algorithm.sxw
[3] http://kohei.us/ooo/solver/
[4] http://sc.openoffice.org/servlets/ReadMsg?list=dev&msgNo=890
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
