4 Oct
2007
4 Oct
'07
6:27 p.m.
On Oct 4, 2007, at 6:19 PM, Erin Schnabel wrote:
[snip]
Well, I was hoping that the plugin could maintain it's own doc inside
itself. That way, it never is out of date. Deploy the plugin, get new
doc. *poof*
ok I understand know. I was misled by the "I propose a space:
XWikiPluginGuide".
I like documentation that comes from the source. There are only 2
caveats:
* external contributors should be able to edit it easily somehow...
* it must be as good as the doc one would write "by hand".
[snip]
I propose a space: XWikiPluginGuide.
Each plugin would have a page in the guide describing: a) how to
enable the plugin, b) what options are used by the plugin, c) how to
invoke and use the plugin, and optionally d) who wrote the plugin
and
the version information (which that document could retrieve via a
getVersion, getAuthor, or whatever call back to the plugin).
I'm not sure I understand. We already have this on xwiki.org on
Code.Plugins. Are you suggesting that this should be bundled inside
the default wiki? If so we need to revisit the whole area of bundling
documentation in the default wiki XAR since right now we're not
bundling any and instead pointing users online at xwiki.org. This does imply creating docs in the local user
install (perhaps w/ an
option). Which would mean, for example, that if you enabled the plugin
on xwiki.org, you'd get the latest doc (under PluginGuide.pluginname
rather than Code.Plugins), w/o having to update two separate places.
That's nice except that xwiki.org may not be running the same version
of XWiki as what it's documenting... :)
Anyway I'm all for it but I don't have the time to work on this right
now...
Thanks
-Vincent