openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Mon, Feb 14, 2011 at 10:25 AM, Thierry Carrez <thierry@xxxxxxxxxxxxx> wrote:
> Jay Pipes wrote:
>> IMHO, we should not be letting *any* significant new code into
>> OpenStack projects without:
>>
>> a) docstrings for all methods -- these turn into our API
>> documentation, so they are critical
>
> Agreed.
>
>> b) Full RST docs for any new feature added. No exceptions.
>
> One issue is that if you see the split in Anne's description, features
> documentation needs to be added to the admin docs (Docbook), not really
> the developer docs (RST), so it's in a separate branch. That makes it
> harder to enforce...

Sorry, I mean RST docs for concepts introduced by a feature patch.

For instance, when live-migrations goes in, I want to see some RST
documentation that explains the concepts involved to developers,
including how live migrations differs from, say, snapshotting.

For user and admin documentation, Anne can ready the concept RST docs
in the developer documentation and work with the authors to produce
user and admin-focused docbook manuals.

my 2 cents and all that,
-jay


> IIUC the dev docs should contain docstrings and a few developer-oriented
> info like "how to do i18n right" or "how we do logging in code" and
> other "this is how we do it" topics. If we add features documentation,
> that duplicates the work in the admin docs (Docbook) and increases user
> confusion as to "where is *the* doc".
>
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>