[Trac] Managing "complex" wiki-based documents
Itamar O
I am wondering what is the recommended method to manage "complex" wiki-documents, and by "complex" I mean documents that are scattered across multiple wiki-articles using WikiLinks.
I have users that are used to writing long specification & design documents as Word documents, and have expressed interest in starting to work in Trac-wiki instead.
As far as document management & versioning is concerned, I would like to allow them to manage their wiki documents at-least as easily and intuitively as file-based documents allow.
The main use-cases include:
- The ability to specify that a wiki-page is a part of a "document" (ideas: page-hierarchy, wiki-properties?)
- Embedding some header / footer in all wiki-pages that "belong" to a specific document with some metadata and a link to the "document root" (ideas: based on solution to previous bullet, inject custom template with a plugin?)
- Allow management of *document*-metadata (as opposed to *wiki-page*-metadata) in some convenient way (metadata includes: organizational-reference, business classification, version info & version history, authors, reviewers).
- Support document-versioning that is *at-least* as good as copying "myDoc-v1.doc" to "myDoc-v2.doc" and updating the metadata accordingly. I write "at-least as good" because it seems that the wiki infrastructure should allow much better abilities, like automating the version-tagging-process, possibly supporting constraints (chain of review-approve), diffs between versions, showing a "jump to" navigation bar between document versions (like in the source browser), etc.
- When viewing a document that "was not released" show a "draft" watermark.
- When trying to edit a "released version" of the document, warn the user and suggest branching a new version.
- Allow automatic generation of document-wide table-of-contents and document-map (like TracGuide) (ideas: if using page-hierarchy, TOCMacro might be able to do it).
- Support document navigation based on flow (something like "next/prev page", with "up" taken care by page-hierarchy).
- Enable "document-export" (for printing / archiving purposes) into PDF / DOC, ideally supporting custom document templates that are populated according to some business-logic (e.g. metadata, list of figures, etc.)
- Allow cross-references between documents that are version-aware, possibly allowing automated generation of "applicable documents" and "this document is referenced by ...".
The TracGuide is an example for such a document.
It contains a table-of-contents (not sure how it is generated),
and version-branches (e.g. 0.11/TracGuide)
(although I'm not sure whether this process is manual or automated - Christian?),
but I listed many other use-cases that are not present in the TracGuide example.
What I would like to hear from dedicated readers who made it to this part (thanks! :-) ):
- Ideas how to implement some of the use-cases I described based on existing Trac (0.12) features.
- Pointers to plugins that may assist.
- Suggestions on how to implement by writing a new plugin.
- Maybe additional use-cases from users with similar needs.
Apologies for the long post...
- Itamar O.
Christian Boos
Sorry for the delay in answering your very interesting mail, but you
sent it right in the middle of my holidays...
On 8/21/2010 2:18 PM, Itamar O wrote:
> Hi,
>
> I am wondering what is the recommended method to manage "complex"
> wiki-documents, and by "complex" I mean documents that are scattered
> across multiple wiki-articles using WikiLinks.
>
To make it short: I'd like to see all of this happen, and this "program"
matches quite closely what I had myself in mind for the future of Trac's
wiki. It will probably take us a few more release to get there, but I
believe it's all possible to achieve.
First, 0.13 will hopefully feature a rewrite of the wiki parser that
will make authoring content more "robust" (less quirks, more expressive
power). Some advanced operations like (batch) copy are also on my list.
I have also laid out a plan for supporting transclusion and other
powerful mechanisms inspired from MediaWiki (see
http://trac.edgewall.org/wiki/TracDev/Proposals/AdvancedWikiFormatting#Transclusion)
which I believe will also provide some of the infrastructure support for
composing complex documents from individual pages. Finally, progress on
the GenericTrac model will bring the addition of wiki properties, as
well as the possibility for plugins to define new resources easily (e.g.
"documents"). In the same vein, a generalization of ticket workflow to
e.g. wiki workflow should also be possible, longer term.
> The TracGuide is an example for such a document.
> It contains a table-of-contents (not sure how it is generated),
> and version-branches (e.g. 0.11/TracGuide)
> (although I'm not sure whether this process is manual or automated -
> Christian?),
> but I listed many other use-cases that are not present in the
> TracGuide example.
>
Well, the table of contents for the TracGuide is generated by a macro,
which contains a hard coded list of pages, and the rest of the
automation indeed relies on me ;-)
> What I would like to hear from dedicated readers who made it to this
> part (thanks! :-) ):
> - Ideas how to implement some of the use-cases I described based on
> existing Trac (0.12) features.
> - Pointers to plugins that may assist.
> - Suggestions on how to implement by writing a new plugin.
> - Maybe additional use-cases from users with similar needs.
Sorry, for /that/ I can't help you much ;-)
-- Christian
Manuel Jesús Recena Soto
Do not think that these characteristics correspond to a Document
Management System?
I'm working on new trac plugin [1] for integrate Trac with DM (p.e. Alfresco).
Regards,
[1] http://clinker.klicap.es/projects/alfrescointegration
2010/8/21 Itamar O <itam...@gmail.com>:
> --
> You received this message because you are subscribed to the Google Groups
> "Trac Users" group.
> To post to this group, send email to trac-...@googlegroups.com.
> To unsubscribe from this group, send email to
> trac-users+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/trac-users?hl=en.
>
--
Manuel Jesús Recena Soto
Founder, CEO & CTO of klicap - ingeniería del puzle
mobile phone +34 664 000 629
work phone + 34 954 894 322
www.klicap.es | blog.klicap.es
Manuel Jesús Recena Soto
El día 13 de septiembre de 2010 13:29, Manuel Jesús Recena Soto
<rec...@klicap.es> escribió:
Itamar O
The only document management systems I am familiar with are systems that manage a "repository" of file-based-documents (e.g. word, powerpoint, PDF, etc.) in hierarchical form with versioning-abilities and metadata-management.
Currently we don't use such a system, and just keep the files in SVN, although it could be very useful to implement DM features over SVN as a Trac plugin.
If you are familiar with other DM tools that allow writing wiki-documents, I'd like to have a look, so pointers are appreciated (although in order to minimize IT-madness, it would be preferable to reduce the number of different tools deployed, which is the reason I wanted to see these features within Trac in the first place).
@Christian-
I'm glad to hear that my ideas fit somehow in the roadmap.
I went over the pointers you mentioned (transclusion and other advanced wiki),
and it seems like more power than what's needed for the use-case I described.
What I'm wondering is whether these features may be introduced gradually (starting 0.13),
in such a way that enough functionality exists in 0.13 (if not before) in order to implement a "WikiDocumentPlugin" based on 0.13.
Probably the most important features needed for this include wiki-properties and namespaces- what do you think?
- Itamar O.