[kde-doc-english] Changes to Stable docs, & future KDE 3.x series releases

[techno_plume-coding at yahoo.com]

Hi.

I'm not clear on the ins and outs, particularly concerning string
freezes, of fixing documentation problems in the KDE 3.x series. 

I saw some changes that could be made in the KPatience manual. I
started editing to a copy of the Docbook file. I was unsure about a few
things,  which I'll bring up in a separate e-mail. I'll illustrate what
I'm lost about using KPatience as an example.

As I understand it:
* Everything under the /trunk directory is in active development for
KDE4.
* Some, not all, applications are also under /branches/$app (or
/branches/work/$app for stuff not in core distribution). /branches is
for working on the KDE 3.x versions of the applications, so new
features of those apps can be added to arrive for users in KDE
3.5x/3.6/7.

I saw some tweaks, grammar and the like, that could be made to the
present kpat manual while browsing the installed version on my KDE
3.5.5 desktop.

Ideally, folks should work on trunk docs. But KDE4 is still a way off.
Is there any value in (also?) working on the documentation to benefit
users of future KDE 3.x series releases?
KPatience is in active development with changes being made to how it
works (new keybindings for example) in /trunk. As far as I know it
isn't being worked on to make a new version for future KDE 3.x releases
as well.

Unless I have a working KDE4 development installation to run the
current KPatience development version, I won't be easily able to write
updated documentation through checking against its changes/new
features.

However, say I propose clarity/grammar fixes for the current KDE 3.x
manual. The manual for the KDE4 version would benefit from these same
changes. In other words, working from an updated index.docbook that had
already had any earlier wording errors fixed, so only changes like new
keybindings or new features normally needed to be added.

In the case of kpat, I decided to work on the index.docbook file in
/trunk. I did this because a) changes reflecting new features hadn't
been added to it yet anyway, and b) I'd make sure to include any
wording  fixes added since the last KDE release. Bug #103079 is an
example of such a fix (though from a while back and already in the KDE
3.x manual). I changed the releaseinfo number to match the application
version in the current stable KDE 3.x release. If somebody patching a
doc made a diff for each release - branch and trunk, then they'd need a
different releaseinfo number in each I suppose.

Perhaps it's too late. Will changes to manuals be able to reach users
for future KDE 3.x releases, including those apps not simultaneously
worked on under a 3.5x branch?

Thanks, 

Richard.