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

Hello Felipe
I agree with you that the different teams work closer together. I do find that the release notes do 
not give enough information when updating. I am finding what has changed by test working in the 
Impress and Draw modules.

Peter Schofield
Technical Writer, LO Documentation Team

On 17 Mar 2021, at 04:30, Felipe Viggiano <> wrote:

Hello Peter and Jean,

I was reading Jean's comment on the issue, and it's quite worrisome that
some dialogs change and we need to keep looking at each one to find, it's
Maybe we can work together with the other teams (UX Team? or QA?) in order
to encourage them to give us at least some kind of list of what dialogs
have been altered. What do you think?

Best regards,
Felipe Viggiano

Em ter., 16 de mar. de 2021 às 05:46, Peter Schofield <>

The pace of software updates is quicker than updating user guides. User
guides have to be checked against the software make sure there is no
glaring omissions in the user guide.

The release notes for each software release should be more comprehensive.
This would make it easier for LO users to cross refer between release notes
and the latest edition of the user guide.

User guides should only have a major update when there is a major update
to LO software. Question is — what is a major update to LO software???

Peter Schofield
Technical Writer, LO Documentation Team

On 16 Mar 2021, at 06:41, Jean Weber <> wrote:

Regarding  updating guides for minor releases, I do not agree with
exclusively on things in the Release Notes. I am finding some differences
between Writer v7.0 and 7.1 that I consider important for users but are
minor for the release notes.

I do agree that in most cases only one reviewer is enough.


On Tue, 16 Mar 2021 at 13:07 Rafael Lima <>

Hello everyone!

Here's my take on this subject.

I believe that when updating the guides to minor releases (7.1 to 7.4)
should focus exclusively on the aspects listed in the Release Notes.
we should take the previously published version (say 7.0 now) and update
only chapters and sections that are directly related to something
listed in
the release notes. If something was not mentioned in the release notes,
then it should remain unchanged.

If we follow this guideline, we can reuse previous chapters entirely.
way, if only a single person reads a chapter and concludes that it has
been affected by any changes in the release notes, then no further
are necessary and no modifications are made to the chapter.

For chapters affected by the release notes, then I believe one person
updating it and a subsequent single review will suffice.

I think this is a great topic for this week's meeting.

Rafael Lima

On Mon, Mar 15, 2021 at 11:31 PM Felipe Viggiano <


Hello Olivier,

Considering your arguments, we need, at least, to think about reducing
cycle review for minor releases reviews.
Kees has a point about the few number of changes in the software to
implement in the guides, and, in my opinion, giving the same treatment
major and minor releases is consuming most of the team's time.
Maybe reducing the requisites for updating the guides in minor
can use the time to work on some other projects.

Is there any idea from the team to implement a reduced workflow for

Best regards,
Felipe Viggiano

Em seg., 15 de mar. de 2021 às 20:12, Olivier Hallot <> escreveu:

Hi Team

I strongly oppose to this approach.

Catching up a full version demands a lot of effort and delays the
availability of the Guides much after the release of the software.

We had a lot of work to bring our documentation from release 4.x to
and now 7.x . We had to skip some releases because we could not match
the release pace.

Small updates and frequent publication (6 months) is, as you see, much
easier to track and provide a good doc for end users. Many chapter
don't need changes and can be fully reused. Other chapters need

Imagine purchasing the latest proprietary software and get a 2y-old
manual in a promise that "will soon be available". Of course
is not a proprietary software and documentation is produced by
volunteers that have their own tempo.

Software with no documentation is a lesser software. Doc and software
are components of a product offering.

Producing a new book with small updates is easier, quicker and may not
require a full cycle review.

My 2 cents


Em 14/03/2021 22:19, Felipe Viggiano escreveu:
Hello Kees,

I was just thinking about that either, perhaps we can focus the
the major releases, such as LibreOffice 7, LibreOffice 8 and so on.

Olivier Hallot
LibreOffice Documentation Coordinator

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


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.