Documentation updates in-cycle?

[Duncan Lithgow]

I've just seen bug 114106 which is a simple case of a URL which point
to a page which has moved (https://bugs.launchpad.net/bugs/114106). I
think this bug could be used as a discussion point regarding this
update discussion. I've decided in this email to call them 'errors'
instead of bugs to underline that we are not talking about changes to
code, but to the text contained in the markup. I'll start by using the
points Matthew raised earlier (I've changed some formatting).

On 07/05/07, Matthew East <mdke at ubuntu.com> wrote:
> I think there are three considerations to balance:
>
> 1. the risk of introducing new bugs - it's possible to introduce real
> bugs, although I doubt they would be that serious - for example, you
> might write some invalid markup that results in scrollkeeper errors that
> end up in people's monthly cronjob error logs. I personally can't think
> of anything more serious than that (and even that would be quite
> difficult to do) but I'm not an expert with Ubuntu and I'm told that
> bugs can come from unexpected places;
I hope we can agree that correcting a broken link involves virtually zero risk.

> 2. the resources taken up by doing the update - when doing an update
> it's necessary to:
> (a) prepare a fix both for the unstable version of Ubuntu and each stable
> version to which the bug applies;
In other words if the error isn't important enough - it won't get
fixed. Isn't that the normal situation?

> (b) make sure the translators know about the change and can translate it;
I don't how this would work. I think this error is language independant.

> (c) import the relevant translations;

> (d) prepare an updated package and submit it to the relevant developer team for checking. > The documentation team is very small and 100% volunteer based and we don't have
> much time.
I think this is addressed by point 'a'. If it isn't important enough
it just won't get done, and that's okay. I also think it's okay if
some people have the attitude that they will only work on developing
the unstable branch and not get involved in fixing errors for stable
releases. It takes all kinds.

Is it far fetched to imagine that some people would happily work on
correcting errors while the unstable branch is too new for them to
help with?

> 3. the seriousness of the bug.
> My personal view is that *probably* when balancing all these things up,
> the bug would have to be high-impact before it justifies undertaking the
> process to fix it, which takes us back to the StableReleaseUpdates policy.

which leads on to...

Tollef Fog Heen wrote:
> FWIW, I agree with this; if you have updates which should really go
> in, the procedure shouldn't block you from doing that. [clip]

So what's the next move? If there's not really momentum to do much
about this then I'm happy to let it rest for this cycle, I'm well
aware that I'm a lurker rather than a worker on this list, so I can't
guage so easily how much is involved... Otherwise; what's next?

Could someone with experience with getting updates through the system comment?

Duncan