sophie gautier wrote:
Hi all,
Hi there!
> [...]
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.
I completely agree with you. And we need to go to the complete
description (issue, specs) to fully understand what the feature is
about.
Many times, comments on the issue help to understand the overall
goal of the functionality where the specs helps to find it and how it
works. So these informations are useful for us (and also for l10n purpose).
Full information for those testing and writing the end-user-Wiki
(without any features missing) would be sufficient, IMO.
Agreed but that´s not the release notes at least that´s not what release
notes currently are that´s end-user documentation, documentation for
l10n work or QA work, ... etc.
So far we´ve only been talking about what´s currently been done when
generating information for the Release Notes!
The Release Notes are something which really should just give a short
and quick overview about what´s new in a release no matter if that´s a
user release or just an interim developer release. It´s not something
that can or should be able to give an desicrption that is sufficient to
'fully understand what the feature is about'.
But hey I am just thinking well maybe we can improve on what we
currently automatically generate by generating two kinds of documents a
comprehensive feature info list for the release notes something like
what we currently have on
http://development.openoffice.org/releases/2.3.0.html and a more
detailed feature-info list for documentation writers, qa, l10n-ers etc.
containing not only links back to issues but also links to complete
feature-announcements and corresponding complete specifications.
and without errors. I don't know if it's the case now, but before I need
to check on EIS to make sure the feature were integrated and at a user
level (Smart Tags is an example so it still happens ;)
That´s the advantage of 'automation' here you don´t have to check EIS if
something got integrated, some program generates information for you
just only about stuff that was integrated and about it´s related
information.
just to make sure
that we don't announce features that are not yet available and that the
pointed issue is the good one.
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 :-)
I agree in that Release notes generation should not be automated
completely there should always be someone to be looking over it before
publishing. And do please keep in mind we were only talking about
Release-Notes not End-User-Wiki pages or other kinds of Documentation
until now.
As I see it know we probably might need two extra things for feature
mails than: a text field for short 'almost' end-user ready description
that eventually can go into the release notes and additionally a flag
for the mentioned case were something got only partly integrated on a
mere technical level and is not completely an end-user ready to use
feature yet to be able to exclude information about this from the
release notes.
Bye the way it´s funny to see how telling again that there´s currently
an automated progress with some requirements to specification writing in
place transforms into a discussion on how we can improve that process or
replace it by a different one ;-)
+1 :)
Kind regards
Sophie
Kind regards,
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
