One thing that you apparently do not understand is that I am not at all
in favor of keeping any deadwood kludges around, as you stated, but to
eliminate them in current and future docs. (I do not know how you
inferred that I favor keeping deadwood. Just the opposite.)
However, if (undocumented) kludges were a part of any current templates
or other docs--such as any remaining artifacts carried forward from
buggy versions 1 or 2 even, just how would you any anyone else delete
them if, in fact, you were not even aware of their existence in the
first place?
My point is that all such esoteric workarounds put into any document,
template, or master document should be adequately disclosed, so that
anybody maintaining or reviewing or editing those docs would know of
their existence, their locations, their effects, their reasons for
existence, and whether or not they are even needed any longer. If LO or
OOo were to use any such mysterious kludges in the future, they should
be appropriately documented. OOo (and LO) rarely ever disclosed their
former kludges in a clear, consistent manner. That's all to my point.
The only good reason that a workaround would have been used in the past
was to act as a temporary band-aid approach due to a bug being present.
Bugs generally get fixed, so after the bugs are fixed, the kludges
should be eliminated in favor of better writing or editing practices.
Gary
On 10/19/2011 2:11 AM, Tom Davies wrote:
Hi :)
I think it has already dealt with by having a fixed set of documentation for
the 3.3.x branch and now making the newer release for the 3.4.x branch. See
the gap at the right-hand-side of
http://wiki.documentfoundation.org/Documentation/Publications
Smart eh?
Some people may continue to prefer to use the work-arounds given as part of the
documentation for the 3.3.x branch even after a bug has been fixed in some
cases.
If you really feel the need to identify which established ways of doing things
are/were due to bugs and which are/were just an alternative way or even a main
way of doing things then feel free. I think Alfresco still has the folders
ready for updating the older version of the documentation. Personally i think
it's better to keep moving forwards where possible rather than to back-track.
The OOo devs were often able to fix bugs and they submitted many patches and
updates that had already been tested by the community but Sun often disdained
to accept work done by non-employees (apparently). That was part of the reason
for forks such as Go-oo. It was probably also part of the reason why so much
was achieved so quickly with the code in early releases of LO when Go-oo and
possibly others re-integrated with LO. At least that's the impression i get
after reading-up 3rd party accounts and hearing from a few disgruntled people
that are much happier with LO under TDF than with anything under Sun.
Regards from
Tom :)
--- On Wed, 19/10/11, Gary Schnabl<[email protected]> wrote:
From: Gary Schnabl<[email protected]>
Subject: Re: [libreoffice-documentation] Template field on the General page of
the document properties
To: [email protected]
Date: Wednesday, 19 October, 2011, 6:14
One major problem with OOo was not
knowing if some of its deficiencies were bugs that might get
fixed or if some bugs would be permanent. (Both MS Word and
FrameMaker still have numerous bugs remaining unfixed from
well over a decade already, and newer bugs are continually
being created.)
OOo would take eons in order to tackle many of their bugs,
as newer bugs were likely piling up faster than their
relatively few developers could fix them. LO seems to be a
lot quicker. A case in point is LO's quick response to its
first 3.4 release bug that would not handle edit tracking
properly (where the copyedited deletions were not visible).
One problem with documentation when bugs are involved is
that such documentation likely consists of workarounds--but
these workarounds are not listed as being bug fixes. So,
some documentation might not be accurate at some point in
the future (or even needed) after any such bugs get fixed by
the developers. IOW, the documents could contain much
unnecessary (or possibly even nonfactual) material.
My take is that all documentation that involves known bug
fixes should be disclosed as being bug fixes--even if doing
that exposes the software suite to some criticism.
Gary
On 10/18/2011 6:09 PM, Jean Weber wrote:
It's been that way for years in OOo. I believe it's
considered a feature: the idea is that for some documents
one might want the template associated with the file (so
when the template is updated, the file pops up the "do you
want to update styles" message); but for other documents,
one might want them based on the template but not associated
with it. As for undocumented: I had written this up in an
earlier version of the Writer Guide, and I thought the info
was still there. Ah, well, my memory isn't what it used to
be. Or perhaps I removed it because the info was incomplete;
there seem to be a lot of non-obvious interactions. Because
of that complexity, this is one of the topics on my list for
extensive research for my proposed book on styles and
templates. --Jean
--
Gary Schnabl
Southwest Detroit, two miles NORTH! of Canada--Windsor, that is...
Technical Editor forum <http://TechnicalEditor.LivernoisYard.com/phpBB3/>
--
Unsubscribe instructions: E-mail to [email protected]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/documentation/
All messages sent to this list will be publicly archived and cannot be deleted
