Doc website branches

[Ian Clatworthy]

Martin,

Beyond the core docs, here are the projects making up our documentation:

doc.b.o/{en|fr|ja|ru} => lp:bzr-alldocs
doc.b.o/migration => lp:bzr-migration-docs
doc.b.o/explorer => lp:bzr-explorer-website
doc.b.o/plugins => lp:~ian-clatworthy/+junk/bzr-plugins-guide/

The last one needs to become a project soon. I've been holding back
until I'm more sure about whether to make it bzr-plugins or bzr-extras.
If it's the latter, the goal would be to have registries of both plugins
and other add-ons maintained there (instead of the Wiki), together with
the docs generated from those registries. Sometimes the line between
"add-on" and "plugin" changes, e.g. Loggerhead, so one project for both
has appeal for that reason.

OTOH, I'm not 100% sure about how sensible a "Bazaar Add-ons Guide" is.
Would it be valuable to have one manual like that documenting each
integration with an Editor, IDE, Bug Tracker, CI tool, etc? Or should
each of these provide their own doc (not necessarily in ReST) and we
make no effort to aggregate them?

My other concern is just how large an "Add-ons Guide" could become. Done
properly, you'd think that "Bazaar Eclipse Add-on", "Bazaar IntelliJ
Add-on", etc. ought to be manuals in their own right. Being honest with
ourselves though, it's more likely the doc for each add-on will be
"light" given 99% of developers prefer coding to writing manuals. :-)
Having an umbrella "Add-ons Guide" might at least encourage *some* docs
via copy-and-paste from other add-ons. Not sure.

Any opinions?

FWIW, if we decide it's useful, an "Add-ons Guide" is low priority for
me. I'm far more motivated to get:

1. better admin documentation (recent list threads have highlighted
   our deficiency there)

2. an Explorer User Guide.

(And I want a few more things streamlined in Explorer before I start on
the latter.)

Ian C.