Hi Martin,
Thanks for joining in the conversation.
Hi,
please, could you further explain:
+ Supporting minor updates to published guides (pdf file)
In fact further examination of what this would encompass the purpose behind
adding it to the call agenda.
The second or third week I joined in on the calls it happened that Olivier
and myself were the only two on board that day. Olivier shared some
thoughts, at length, on treating the Guide publication process more closely
to how a software package is released. With an important goal, among a few
others, of bringing Guide publishing dates closer releases of the software.
The idea has been bounced around between others on a few subsequent calls.
What I've taken away from these discussion would be to have a work flow
which supports major and a minor publication of a Guide.
A major publication of a Guide would involve updates to every document
(master document and all chapter/appendix documents) along with other
components such, cover art for one example.
It could add or remove chapters or make other changes in chapter structure.
It includes the production of two set of documents, one including an ODF
master document, ODF text documents for each chapter or appendix and the
other set pdf files created from the first set.
The publication process includes then the production of an official print
master, including ISBN registration as a final update, which is then sent
to a print service.
This represents the current publication process.
Publishing a minor version of a Guide could, but may not, require a change
to the master document beyond generating new TOC/Alpha Index tables, it
would include updates of some subset of chapter or appendix documents.
A minor publication process produces both sets of files, ODF and PDF.
No print master is produced for the minor publication, therefore no
registration of a new ISBN is needed.
***I have some open questions regarding the last point about the ISBN and
if there might be some legal requirement of a clearly distinct name from
the registered printed book, even if true it is just something to account
for in the workflow.
These minor publishing events would happen between the full, major, Guide
releases.
This change would require us to change the file names to include a document
release number in addition to the software release number, only those files
which actually change would increment the document release number so that
at a macro level you could easily see which of the constituent files
actually changed based on the file names in the release.
What is the agreed notification workflow with every guide update for all
l10n teams translating these guides (content-wise, i.e. notifying "this
sentence in this chapter/page was changed from this to this" etc.) so that
the translation process continues with the really-latest version (after an
official version is already published) and as hassle/confusion-free for
l10n teams as possible?
There would always be, at a minimum, the ability to generate a delta
between the present and most previous copy of an individual file to see
what exactly changed with the compare documents function using ODF files.
With the delicate translation process going on in parallel with the
considered minor content updates I would instead suggest to create odt/pdf
with errata or corrigenda of a guide (and all its chapters) that gets
updated regulary and is finally merged with the guide only with its next
iteration of publication.
If publishing were always going to dead trees for a medium I'd say
absolutely the better way to go.
That is need not be the case here however and I would put forward some
opinions:
No document of this type publishes without deficiencies either by error or
omission.
It is valuable to make the most accurate information available to users as
quickly as reasonably possible.
The quicker the team can get feedback from users seeing the changes made to
address these deficiencies an the more readers overall increases the teams
ability to make higher quality documents.
I think publishing complete documents, with changes incorporated, will
generate both better and more feedback than a list of changes in a separate
addendum document.
As I said above this is really the first time I've put what I've taken from
our batting the idea around on a few calls into text and thanks again for
the nudge here.
That then is just a gross view of the thinking and certainly needs more
fleshing out.
Given that it's 1AM here though it is a good spot to end this email.
I'm looking forward to continuing the conversation with you and others here
on the morrow.
Looking forward to hearing your thoughts.
Best wishes,
Drew