we are currently evaluating XWiki as a new solution for our product documentation.
So far we have been working with Word. The Word-files are used to create PDF-documents that are available for download on our website. For several reasons, we want to replace this process by using a different system and XWiki seems to be a good alternative so far.
However, we currently have some open points/problems with the mapping of our workflow in the publishing process.
Up to now, a new document has been created and edited by one author.
The document is then proofread by a second person. In the process
changes are made and marked as such in the text,
comments are left directly in the text (e.g. if a paragraph is unclear or ambiguous),
all this is done in Word’s revision mode, which makes it easier for us to see the differences between the original text and the revised version.
The author receives the revised version of the text for approval before the document is published.
Each individual change can be accepted or rejected. (XWiki only allows the whole text to be accepted/rejected).
After beeing finished, the document is then converted to PDF and published.
How do you realise this?
Are new texts entered directly into XWiki?
Is there a better overview to identify changes and do you have any idea if and how individual changes can be discarded?
Are there any plugins for this usecase? We have already looked at the change request application, but the workflow seems very complicated to us.
editing and version management is paramount to xwiki, so every change to a page is stored in the history tab under a page, this allows rolling back changes or gives insight into how a page came to be.
For your work proces (what I’d do) is use the inline annotation feature; like in word you can highlight text in xwiki and then hit control + m to comment to that part of the text:
In the comment section you can see a link to the annotated area and the critique
I’d look into making a class that has a published/not published variable to track the status of the document and then track the comments underneath each page to see if there are open/points problems.
I’m using a similiar setup here (on work forms instead of product documentation) , but I think the workflow is identical; people can comment on the document, then I have a seperate app on which I log changes on that form… when you work on the document I cut / paste the comments to the changelog page; make changes and wait for people to agree on the new version. Then the form gets published and goes up a version - resulting in a clean log of the changes made:
It’s a bit of fiddling with velocity and the (AWM) classes but its turned into a very powerfull system, the beauty of xwiki is you have the flexibility to course/correct- adapt as needed.
If you dont mind the dutch! heres how the formoverview looks;
There is a draft of an extension for a simple published status but I don’t think it has been published to the extension repository yet. @tkrieck what’s the plan regarding publishing this extension?
There are some bugs on the extension now, namely the need to reload the page for the color change to take effect. After that I think the ext can be published.
heres how the formoverview looks;
