Re: Bugtracker cleanup/update

[Graham Percival]

On Sat, 31 May 2008 09:28:50 +0200
John Mandereau <address@hidden> wrote:

> An unsure question is, should big doc work like GDP go on on master
> after 2.12?

No, because barring a miracle, there won't be anybody[1] left to do
big doc work.

[1]  Trevor, I mean no offense whatsoever when I imply that you're
nobody.  :)

> I started backporting doc changes from master to stable/2.10 when
> 2.10 came out, but I got tired after a few months and gave up, it
> would be cool if several people could handle this.

A lot of things would be cool.


Once GDP is over, there shouldn't be any need for big doc work for
the next five years or so.  If there is, then it will have been a
failure.  Also, when GDP is over, the amount of people working on
the docs[2] will be cut by about 90% -- Trevor will be the only
person left.  The translators will go back to translating, and
other people will contribute to LSR.  Trevor and Neil (and
possibly Carl) will maintain the docs, but this should only
consist of modifying which snippets we include in the @snippets,
running makelsr.py, and occasionally adding info about new
features.

[2]  By "the docs", I mean the .itely files.  Again, I mean no
offense whatsoever when I imply that Neil is nobody; it's simply
that his main job is maintaing snippets.  :)


* the one caveat is docs about programming in scheme; I believe
that Trevor would like to rewrite that chapter.  I highly
doubt that we'll get to that stage during GDP... but it will be
easy enough to backport an entire .itely file to stable when he's
done.


Really, the whole point of GDP is to reduce the burden of doc
maintenance.  Barring writing new docs for new features (which I can't
predict), I expect that maintaing the .itely files will be about 2
hours per month (not counting reading email), and the snippet
maintenance to be 1 hour per month (again, not counting email).
Furthermore, these jobs can easily be done by separate people, so we
don't need to overwhelm one poor sap.

Cheers,
- Graham