Much-delayed detailed responses to some of David's workflow
suggestions are interleaved below in his note. I may respond to others
in a separate note. --Jean
On Sun, Aug 5, 2012 at 3:42 AM, David Nelson <comme...@traduction.biz> wrote:
>
> OK, the workflow we originally set-up on Alfresco...
> The doc start in the "Drafts" folder. A considered-ready
> draft gets approved and goes forward to the "Review" folder. A
> reviewer proofreads it, and either it gets approved and gets moved
> forward to the "Publish" folder, or it gets rejected and goes back to
> "Drafts".
IMO it is better for reviewer and editors to do their work (using LO's
change tracking tools) and then let the author (or someone else)
review those edits and comments and accept/reject them individually
before approving the doc and moving it to the Publish folder. We
typically do that all within the Feedback folder, though it could be
done by returning to Drafts.
I mention this because in this case, as with some other suggestions
you've made, the workflow concepts of what we are doing (write,
review, edit, publish) are getting mixed up with how to handle the
workflow within the tool (Alfresco).
> The act of approval or rejection (it wasn't always actually
> used) was to click on one of two menu options in the right-hand menu
> that appears when your mouse pointer hovers over the document. The
> result was that Alfresco would move the document to one folder or the
> other.
That's fine with me, and in fact I quite like that process.
> When the doc actually lands in the Publish folder, the bells sound and
> the doc gets published.
>
> This is a manual process... [details snipped]
>
> Questions: Is there a real need for more than Draft/Review/Publish
> folders? What is the real value of the Feedback folder? Could we
> usefully just eliminate it and simplify things?
The Feedback folder is used as a place for members of the Docs team to
submit docs they have reviewed or edited as part of our normal
process. "Feedback" probably isn't the best name for it; "Review" is
probably better. The purpose is the same.
> Question: The workflow described on the wiki involves 4 roles -
> Writer, Reviewer, Editor, Publisher. Could we usefully simplify that
> to Writer and Reviewer? Editor and Publisher could potentially be
> eliminated, because of my file-naming suggestion below.
At ODFAuthors, in the English team we have two roles within the
software itself: "Author" and "Manager". "Authors" have the authority
to write, review, edit, publish. Within the conceptual *workflow*
(that is, what people do, separate from what the software does),
however, we distinguish between writing, reviewing, editing, and
publishing roles. [Aside: some language groups may do this
differently.]
>
> Suggestion: On Alfresco, you could usefully revise the file-naming
> conventions. Keep the conventions as regards the title of the manual.
> But remove the version info from the filename. Instead, decide what
> fields you want to have in the meta data of each file, and store the
> version info in there only. The advantages I'd see are discussed
> below.
> [...]
>
> Possible different solution
> ===================
>
> Have 2 folders for each manual: "Work-in-progress" and "Published".
>
> All work gets done on the file in "Work-in-progress" and there is only
> ever one file for each chapter of a manual in the "Work-in-progress"
> folder.
>
> Alfresco's versioning system updates the version number of the file
> each time someone uploads some work done (via "Upload new version"
> under "More..."). One can easily roll back to a previous version
> number if necessary, or download an old version number if desired.
>
> Each worker enters a comment in the Alfresco comment box when
> uploading, stating the work done (and/or in a comment field in the
> document meta data).
This is over-simplified and will probably cause workers to lose track
of what they should be doing. See comments elsewhere in this note.
Although, a variation using sub-folders under Word-in-progress for
drafts, reviewed, and edited could work.
> The same file is used even when work starts on updating a chapter to
> take account of a new version of LibreOffice. In this case, the
> LibreOffice version number is updated by a team member in the file's
> meta data. You don't have to worry about incrementing any file version
> number in the meta data, because Alfresco is handling the version
> numbering.
We need to create chapter and book files for new each version of LO
with new filenames, not just in the metadata. This because we keep
files for more than one version of LO on the wiki, and those files
must have different names.
> When the file is finally publication-ready, one uploads it ("Upload
> new version" in "More...") as a new version of a file of the same name
> already existing in the "Published" folder.
Only for updates (corrections) to existing published chapters.
> That existing file is
> already linked-to on the wiki and on libreoffice.org (the link comes
> from the public browser on http://media.libreoffice.org), so there is
> nothing to update and no further action is necessary (except
> generating a new PDF file for the entire manual).
No. See above.
> The same naming simplification for PDF files would eliminate the same
> wiki/libreoffice.org drudgery as for the ODT files.
Related thought:
I use the date and initials on files that are works in progress to
track them on my own computer as well as to get a quick overview of
who has changed a file and when -- without having to consult the
metadata.
I find this extremely convenient and simple. While I can go back to
Alfresco and download an older version of a file if I want it (or look
in the metadata to see when and by whom it was changed), in most cases
that is a nuisance compared to having it on my own computer with the
info in the filename.
That said, I appreciate that Alfresco is more convenient to use with
one unchanging file name for each version of LO. I can manually change
filenames upon download if that makes the whole process easier for
everyone.
I would like to know if others find the date-and-initials file
suffixes useful or if they are irrelevant to the way you work.
>
> On the wiki page, eliminate the publication dates (removing more
> arduous manual work). Don't most people just want to download the
> latest available version? One can always just post on the blog when
> one publishes a new version, if one wants to.
Users have specifically requested dates on the wiki page, so they can
easily see whether there is a new version (update) of a chapter or
book that they might already have a copy of. They won't go trawling
through the blog (if they are even aware of the blog) to find out
whether something new has been posted.
>
> Possible further simplification
> ======================
>
> Just publish PDF files as the final deliverable to the public - one
> PDF file for each manual.
Providing chapter files, not just the full manual, is IMO a service to users.
>
> Personally, I *never* consume documentation in .odt form, I *always*
> prefer an entire manual in one PDF file. For me, a .odt file is a
> working medium not a consumption medium.
Others may wish to use .ODT files for easier amendment, translation,
etc. We have to produce them before creating the PDFs, so why not make
them available to the public? (Other than a bit of extra uploading on
our part.)
>
> A PDF file can be opened on almost any computing device. A .odt file
> specifically requires LibreOffice to be installed.
No, it doesn't. It can be opened in other programs that users might
have. However, that is IMO irrelevant. Let people choose what is best
for them.
Another suggestion that has been made is to produce and provide hybrid
PDFs, which can be opened in LO for editing or in a PDF reader for
viewing. I would not consider these to be a substitute for providing
ODTs for those who want them, and I am a bit reluctant to create
hybrid PDFs because of the increased file size. I am acutely aware of
the problems some people have, if they are on dial-up, a slow
"broadband" connection, or an expensive connection such as mobile
devices sucking data off a 3G/4G connection.
--Jean
> Conclusion
> ========
>
> OK, I think I've covered everything that comes to mind right at this
> moment, but I'm trying to find ways to reduce the workload and to
> simplify contribution, as this will take weight off current team
> members and possibly encourage more people to volunteer.
>
> Responses and counter-suggestions?
>
> --
> David Nelson
--
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
