Hi,
Bernd Eilers wrote (14-11-2007 16:03)
Cor Nouws wrote:
Eike Rathke wrote (14-11-2007 12:07)
Bernd Eilers wrote:
What I consider bad on using this fallback is the problem that the
feature-info is often to technical to be used for the release notes,
eg. it´s often mentioning stuff like ChildWorkspaces where
something got integrated etc. which the end user doesn´t know about
what this is but well that may be only my impression.
That's a matter of education then. Developers should get acquainted with
the idea that feature announcements should be written such that they're
end user compatible ;-)
We could also agree on something like tagged sections, such as a
[technical]
blah here
[/technical]
would not be included in a compilation of feature announcements. Using
square brackets instead of angle brackets would prevent confusion with
HTML tags if the text is to be included in some HTML page like a wiki or
such. The EIS form could actively support that by offering two
textareas, one description for users, one technical.
Well than I suggest we would better have that user info for the release
notes just completely as a separate field when writing feature mails as
descriptions tend to be one or a few pages of text long while for the
release notes we really only need one or two sentences.
IMHO the following is where it comes down to.
A)
Information is needed for:
a - testing
b - writing Help / documentation
c - writing feature info for Wiki / marketing
An example of C: [1]
Note that it holds relative short descriptions. It is to make people
aware of functions, maybe even to attract them, but not to replace A.b
Also note that improvements/suggestions for future versions are welcome :-)
B)
The most important source for this information are the release notes.
C)
And the better these are gathered (clear, covering all features and
pointers to further info) the easier the information a, b, c is created.
D)
A more automated process as well as good habits among developers is
important to C.
If (as long as) this is the situation, the following is IMO true:
For general users and marketing, easy understandable wording is
important.
But for people preparing the end-user-Wiki (for that purpose) more
technical info can be useful.
Also, it's not the job or competence of a developer to write end user
compatible, is it? Would be a pity if that took a lot of effort.
That´s why it´s a "semi"-automated process which means there´s some
automation that generates info about new features for release notes and
someone does a copy and paste with that into the release notes along
with other release info stuff and there is the chance to change stuff
before publishing those release notes, this is how it was done until now.
I agree with that.
Also I think editing by a human living will stay necessary to provide
information A.b and A.c
Bye the way: if for that release notes semi-automated generation process
we only use the feature mails in the future like suggested here
generating that document for release notes preparation will get faster
as we wouldn´t have to download and parse all those specification
documents anymore.
OK. That's about D, which is beyond my competence.
[1] http://wiki.services.openoffice.org/wiki/New_Features_2.3#Full_list
--
Cor Nouws
Arnhem - Netherlands
nl.OpenOffice.org - marketing contact
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
