qwhatsthis experiment

Carlos Leonhard Woelz carloswoelz at imap-mail.com
Sun Sep 12 00:20:57 CEST 2004


Hi Tom,

I am looking forward to working with you in this qwhatsthis idea.

On Saturday 11 September 2004 07:15 am, Tom Albers wrote:
> Op vrijdag 10 september 2004 22:42, schreef Carlos Leonhard Woelz:
>
> > 2) Proofread the text, make it follow the doc guidelines.
>
> Is there more info on that?

Sure.

There are general writing guidelines in the doc-primer:
http://i18n.kde.org/doc/doc-promer
See the english guidelines and writing tips in chapter 3.
The doc-primer is still a work in progress, but it is useable already.

Also, the ‘Visual Guide to KDE’ has the official names for the widgets:
http://docs.kde.org/en/HEAD/kdebase/visualdict/visual-dictionary.html

We can write specific whatsthis guidelines later.

> > 4) Find the code in kde cvs related to the whatsthis.
> > 5) Edit the .ui or c++ code to add the submission.
>
> Found a nice manual at
> http://urbanlizard.com/~aseigo/whatsthis_tutorial/

I know this one ;) I used this guide to do my first submissions to KDE. Untill 
now, Aaron never gave me permission to copy it to the quality guides. So I 
only link it to from docs howto.

http://quality.kde.org/develop/howto/howtodocs.php
(Note that this page will be redone when the doc-primer is ready.)

So we have two options to use this info in our guides: rewrite it, or ask 
Aaron again. Hey, Aaron, can I use your text in the quality guide?

> > 6) Send the patch 
> > to bugzilla, or to the maintainer / devel list. 
> > Bugzilla option requires more work, while the devel list  can be a black
> > hole for patches.
>
> I think we should make a list of apps where we can commit directly and for
> which a patch to some ml is requested, etc.
>
> > 5) It does not scale well: the things you learned about one app do not
> > apply to the next one. Also, most satisfaction goes to the ones who
> > create the whatsthis and most work goes to the ones who create the
> > patches, so this is hardly a motivating first task.
>
> Well, i prefer the less motivating task.

I am glad to hear that :)

> > On the other hand, developers, power users or long time KDE users may
> > find this easier. One solution is that we should not check the content
> > as a rule, only create the patches, check the spelling and guidelines
> > conformance. The maintainer should apply the patch if he thinks it is
> > OK, or simply drop it if it is not.
>
> _That_ would not be motivating.

Well, if you check the info, I am sure the maintainer will apply the patch. 
And if it's not ok, ask for feedback, so you can correct it and send it 
again. Sorry about the use of the "drop", this should not happen very often. 
In my experience, if the maintainer has any objection, he simply corrects it 
and apply it.

Cheers,

Carlos Woelz


More information about the kde-quality mailing list