Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index



ANYTHING
Anything to help get the documentation out faster with the items that need to be up-to-date.

Actually, having the end "changes for 3.4" or "changes for 3.5" might work well.

Maybe have a footnote in the original pages to point to the 3.4 or 3.5 chapters would help as well.

But for my mind, getting the documentation out there quicker, and easier for the writers as well, will be a help to every one of us who wants to promote it, software and documentation together.



On 04/01/2012 02:01 PM, klaus-jürgen weghorn ol wrote:
Hi Jean, *,
Am 31.03.2012 02:11, schrieb Jean Weber:

We've been talking about two possibilities, each of them involving
*not* attempting to update everything for each release.
1) Only update chapters where significant changes are required (UI
looks very different; major new features; corrections to errors). In
most cases, most chapters need only trivial, or no, changes to keep
them current, although the writing in some of them can still be
improved.
2) Combined with 1), only attempt to release a new version of each
book once a year.

What do you think about taking the version 3.3 (or 3.4) as base document, no change of the content, and put in an own heading at the end of the chapter called "new in version 3.5". There will be a list or some descriptions of the changes. Only this piece must be written and be proofread. The front page will tell "Version 3.3 with explanations for 3.5" or so.
We can also take these headings and make an own chapter for it.
With 3.6 there is then a next heading (or chapter).

So there is no need for reviewing the existing content and we can take the available wiki pages and informations.

Only if there are important changes or we find the persons to work on the whole book, we change the content and the screenshots.

The big work will then be with 4.0.

But the main problem is that, although we have many people who say
they are willing to do proofreading (copy-editing), that's not much
help unless there are enough people who (a) know how to review the
content for accuracy; (b) can use existing info (such as the list of
new features) to know what to look for and incorporate changes when
needed; and (c) have the time to do the updating and writing, to get
things to the point where copy-editing (proofreading) is useful.

Maybe we try my proposal with the Calc Guide, make a wiki page with:
"What are the changes in Calc from 3.3 to 3.4 to 3.5", take in the structure of the Calc Guide and the informations we find in the wiki.

On a wiki page some more people can work with.

I'm ccing the document ml to get their opinions. At least we should take the whole discussion to that ml?!



--
Unsubscribe instructions: E-mail to marketing+help@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/marketing/
All messages sent to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.