From: Gary Schnabl<[email protected]>
Subject: Re: [libreoffice-documentation] bugs and work-arounds
To: [email protected]
Date: Wednesday, 19 October, 2011, 12:24
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
