Review Request: Adds support for Share-Like-Connect, making khangman activity enabled
sebastiangottfried at web.de
Tue Oct 30 13:14:50 UTC 2012
> "At one point in future, every user will just expect that applications
> support this, no need to restate that in every single handbook." ->
> How do you *really* know that "every user" will be well-acquainted by
> default? I am sure that is not going to happen as the time continously
> tells that users need as much help as possible. If there is any
> feature related to the project, it should be documented in my opinion.
> Like I wrote in my previous email, there is quite a few generic
> features already documented (again, one typical is the shortcuts, but
> one could say ghns/kns et al), and I do not see the point of breaking
> that. I really like the self-containment. Will 1-2 lines for a feature
> bother anybody now if it had not been like that for years? :-)
All true. I didn't make my main point clear enough. S-L-C is not an
application feature (even if the application obviously need some code for it),
its workspace feature.
Every user will look in workspace handbook if he want's to know more about it.
Also the availability of the feature depends on the workspace the user
employs, so stating support for a thing which may or may not be even available
is not helpful.
All you can safely do is saying "This application supports the KDE Activities
System" What's the help of that?
> A good self-contained handbook may also help someone with testing the
> features available in a project if there is no test list available yet
> for the quality team.
There we have a small stakeholder conflict between giving helpful information
to the quality teams and giving maybe confusing information to end-users. I
opt for the end-users.
At the end of day, I want stop anyone to add such information to the
handbooks, I only think our manpower is rather limited (as always...) and the
should focus on more important things.
More information about the kde-edu