Doc website branches

[Martin Pool]

2009/10/30 Ian Clatworthy <ian.clatworthy at canonical.com>:
> 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.

I think 'extras' or 'add-ons' is a proper superset of 'plugins',
including as you say things like IDE or other tool integrations.  I
don't see why you'd want a list of only plugins and no other extras, I
think splitting it into two will just make things harder to find, and
I think having a list of plugins that includes non-plugin extras will
just be confusing too.  Therefore, I think one larger 'bzr add-ons' or
'bzr extras' guide would be great.

I'm not sure if these things really need to be in separate trees -
obviously the explorer site belongs to explorer, but do the others
need to be separate?  If you find it better so, that's find.

> 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?

I see the add-on guide as being a bit like a Good Food Guide for
add-ons -- the point is to tell people if they're interested and to
give enough data to do more.

-- 
Martin <http://launchpad.net/~mbp/>