It seems like my suggestion should have been to simply include a link to a wizard on bugs.kde.org, with a special flag like documentationUserResponse. The rest is not necessary.
If someone else could implement this extra link in the khelpcenter and docs.kde.org (before the freeze?), I volunteer to triage the documentationUserResponse's into useful bugs. I was looking at this mainly from a user perspective, where this link could allow them to be interactive in the documentation process. I think it would also make the system seem more modern. Will Entriken On Mon, 24 Jan 2005 17:12:51 +0100, Lauri Watts <lauri at kde.org> wrote: > On Saturday 22 January 2005 18.13, Full Decent wrote: > > Forgive me if this is the wrong destination for this proposal... > > > > I am proposing the idea that all documentation for KDE projects and on > > all KDE websites include links to provide online feedback on that > > documentation. > > > > At a minimum, it will very useful to see at the bottom of each page: > > > > -- Was this information helpful? > > -- Yes > > -- No > > > > Many other sites do this now... but we should also do the following if > > the user clicks on No: > > > > -- Please tell us what was wrong with the documentation: > > -- It was not thorough > > -- It did not apply to me > > -- It is outdated > > -- It was inaccurate > > Adding something like this to pages is trivial, to either docs.kde.org or the > docs in khelpcenter. However, are you volunteering to triage this > information, and file bugs for the valid problems? > > If you are volunteering for such a thing, why don't you just start reading > through documentation, comparing it against the applications, and filing bugs > directly - saving the need to clutter up of every page of documentation? See > the good work Virgil has been doing in this regard - this is very useful to > us, and immediately productive. > > > Internet conectivity, what if they don't have it? > > When the user clicks on yes or no, or subsequenly "It was not > > thorough", etc, there should be a background process that "queues up" > > these responses. This daemon will save the response data to a file. > > The next time there is internet connectivity, it should use curl or > > something and request URL's like: > > > > http://www.kde.org/documentation/feedback.php?document=0103983&response=4 > > > > We have an issue tracking system already: bugs.kde.org, product docs, and > could easily provide a link to start the bug wizard with the starting > information filled in. bugs.kde.org requires an account be opened though, > and for good reason. > > > Do you think this method provide valuable feedback for the > > documentation project? Do you think this would be technically feasible > > to implement? > > No, I really don't, at least in the form you outline. A daemon to deal with > docs feedback is really overengineering things, when a simple prefilled with > information email link or bug report is fine. > > It would be technically feasible, but unless we have more hands on people > doing the work, it would simply overwhelm us with unfiltered data to sort. > Someone getting personally involved and filing specific bugs with issues to > be corrected, and/or providing patches to fix these issues, is much more > useful. > > The problem is really not lack of feedback - it's simply lack of people > writing. > > Regards, > -- > Lauri Watts > KDE Documentation: http://docs.kde.org > KDE on FreeBSD: http://freebsd.kde.org >
