On 6/14/2012 2:23 AM, Jean Weber wrote:
On Thu, Jun 14, 2012 at 2:31 PM, Gary Schnabl<gschn...@swdetroit.com> wrote:
On 6/14/2012 12:19 AM, Gary Schnabl wrote:
On 6/13/2012 8:18 PM, Tom Davies wrote:
Hi :)
Is the 3.6.x usable enough to completely skip all the remaining 3.5.x
guides and go straight to the 3.6.x guides instead?
Regards from
Tom :)
My dos centavos...
Due to the very small number of writers available, LO should always
rewrite its current material at the beta version level, at least. Better
yet, write for the pre-release alpha stage and update the chapters
accordingly, as needed.
Otherwise, when the LO docs project attempts to complete an incremental
edition, it will likely keep remaining an incremental version or three
behind--and possibly contain deprecated or even worse, obsolete, material in
addition to being untimely.
Gary
I forgot to add...
The writings should be done much like the technical editing and rewriting we
performed for Motorla/Freescale Semiconductor: using conditional text for
the various material that differs. After a reasonable amount of time, the
obsolete or deprecated material can be permanently deleted.
Gary
Gary, you know perfectly well that very few volunteers are able to
cope with conditional text or any of the other professional methods of
maintaining documentation. Otherwise, I would agree.
As for working with beta software, this is also a problem for many
volunteers. We've seen that over and over again at OOo and here.
However, I'm far more willing to tackle that problem. Of course, some
of our regular contributors have no problem with using upcoming
releases, so that's not a showstopper.
See my other note about my conclusions from studying the features
lists for v3.5 and v3.6.
--Jean
For those who might be unaware of the use of conditional text...
Using conditional text is not as complicated as you are making it seem.
Reviewers or re(writers) could work as before with their writings or
reviews.
Afterward, a maintenance editor (a type of technical editor who updates
docs) could then incorporate the conditional text into a master chapter
document, as needed. As a result, any desired incremental version could
be generated, utilizing the appropriate conditional field for the
particular version. And the final port of a particular version's chapter
is (typically) cleared of its conditional text for the master document
used for book building, assuming that a book or PDF is the desired output.
All of that could be made transparent to those writers, editors, or
reviewers with less experience. There were times in the past (mostly for
version 2.x, when there were a bit more volunteers at times than
currently) when OO had maintenance editors assigned to chapters, thus
aiding in updating those chapters of the Writer Guide.
Of course, the problem in that regard is a current lack of maintenance
editors--something that could be corrected with an aggressive
recruitment of volunteers (no easy task). Another benefit would be
keeping the modularity involved when a guide is broken up into chapters
along with their attendant maintaining editors--much like it was a few
years ago.
One problem was LO/OO reinventing the wheel over and over again when
redoing a complete incremental edition with mostly unaltered material,
thus resulting in some delays in getting out a complete increment guide
for whatever component being developed. But the real delay at LO is not
getting an appropriate leg-up with new material while not starting the
updating until way past the time the incremental version is already in
its general, stable release.
Gary
--
Unsubscribe instructions: E-mail to documentation+h...@global.libreoffice.org
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
