[kde-doc-english] Documentation feedback

[Full Decent]

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
>