Steven:

Looks like you've covered all of the bases so far.  Just a few minor, high-level suggestions below.

-Mike

I wonder if mentioning Extension Hooks by name this early is more confusing than useful.

Maybe something more like:

"Review Board's functionality can be enhanced by installing a Review Board Extension.  Writing and installing an Extension is an excellent way to tailor Review Board for your exact needs."

When you say "conventions", it reminds me - we should mention that we've designed the framework to follow many of Django's conventions.

We should mention that when an extension is disabled, tables for models are not dropped.  The user would have to use

./reviewboard/manage.py evolve --purge

In order to generate evolutions to drop those tables.

Continues to look good.

"an" Extension.

And I'm not sure we need to capitalize Extension everywhere, unless we're referring specifically to the Extension class...

easy to use -> easy-to-use

Another thing we could mention, is that evolve is also run programmatically.  That way, an extension's models can change over time.  The developer just needs to update their model definitions...I don't think they need to enable/disable the extension to trigger the evolve, but you should double-check.

is created?  I think we mean "should be created".

This is only one part of the puzzle - install_requires will ensure that certain packages are installed in order to make the extension install successful - but it doesn't describe how we can have extensions be dependent on one another.

A "requirements" list can be declared in the Extension class that gives the names of extensions that must be enabled in order for this extension to be enabled.

I just had a few nitpicks to make.

I think there should be a comma after minimum.

We should probably be consistent in capitalizing Python (here and below).

Either use a lower case Extension or change it to subclass.

comma between 'information' and 'see'.

- Seems like this line was swapped with the next.
- Add a comma between 'information' and 'see'

in to => into?

in depth => in-depth

extensions => extension's

auto detection => auto-detection

For some documentation on template hooks see: http://code.google.com/p/reviewboard/wiki/Building_Extensions#Adding_a_Template_Hook

The docs look great in general. You're going to see the same few comments from me listed a dozen times each. Just some stylistic stuff, and we should also be better at linking to external docs when we talk about them.

Two blank lines before each section.

Should have a space before the <..> in links. Same for all others.

Might be nice to do "<extensiondir>" instead of "sample_extension". Or put it in italics, actually, since that's how the the docs typically indicate something that's to be replaced.

Two blank lines.

Two blank lines.

"For" ?

One blank line between each of these. Same for others in the class.

Two blank lines.

When referencing filenames or directories, use :file:`..`

Two blank lines.

This is fine for development installs, but people developing against a Review Board install are likely to use rb-site. In that case:

    rb-site manage /path/to/site evolve -- --purge

I'd say just nuke this if we don't have content yet.

No blank line.

Two blank lines.

Wrapping is funky here.

Two blank lines.

:guilabel:`Configure`

:file:`admin_urls.py`

:file:

Two blank lines.

We should link to it.

Should be capitalized. Here and the next entry. Also, only one space.

Use `` for the module name.

Two blank lines.

Alignment is wrong.

:guilabel:`Database`

:file:

Link to it.

Two blank lines.

:file:

Two blank lines.

Alignment is wrong.

:file:

Two blank lines.

Two blank lines.

Only one blank line needed.

Two blank lines.

:file:

Two blank lines.

We should be linking to the docs instead of just listing the module. Same at other places.

:file:

Same here about linking.

We should mention that this is part of the Review Board tree, and will require a checkout.

(Really, we should turn this generator into a management command, or otherwise make it available externally.)

As discussed in IRC, this is a great start, and we can add more stuff as we go along.  Thanks Steven!