Cor Nouws wrote:
Hi Eike, Bernd, *,
Hi there!
Eike Rathke wrote (14-11-2007 12:07)
On Wednesday, 2007-11-14 10:06:21 +0100, 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.
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.
Full information for those testing and writing the end-user-Wiki
(without any features missing) would be sufficient, IMO.
Unless of course, a situation can be achieved where the system and
procedures can expected to produce info that:
- always has all features;
- is well understandable for end users;
- directly exports to the feature announcements-page.
In that case, extra effort for the end-user-Wiki as it is now, would be
useless :-)
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.
Regards,
Cor
Regards,
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
