KDE Usability Improvements

[Carlos Leonhard Woelz]

I fell guilty for prolonging this discussion, (specially because I have not 
been working a lot on KDE recently). But I have fun with KDE even if I am not 
a "coder", so please allow me to present my side of this story:

On Tuesday 19 April 2005 21:08, James Richard Tyrer wrote:
> We seem to be headed towards what I regard as a serious issue.  Those
> that write the code seem to feel that only they should make all design
> decisions.

I don't agree. Really. I have filled good bug reports that have been ignored 
for a long time. What do I do? I check for every major KDE release if they 
are still there, and add a comment "still here". You, as a bug reporter, must 
know that it is the right of the "coder" to ignore you, as he is a volunteer. 
But if you write good reports, you increase the chance of the bug being 
fixed, decrease the developers time tracking bugs and solving them, and with 
good comments, help designing a better solution. But there are no guarantees.

It is your right to argue if you think you are correct. But if you do this 
without proper backing, people will pay less attention. Flamewars will make  
people skip your mails. Be constructive, and they will listen to you. 
Sometimes people do not get what you mean the first time, it is normal.

<snip>

> I digress to note that I used the term 'coders' rather than developers
> because although 'coders' *are" developers, all developers are not
> 'coders'.  We must realize that designers, testers, and bug reporters
> are also developers.  In a large project, division of labor is
> necessary.  While I am able to do all four jobs, there are people that
> are not.  There contributions should be accepted even though they do not
> write code.

I don't think so. Quite the opposite: "coders" *love*  designers, testers, and 
bug reporters (and artists, and documenters). They do pay attention to you 
after you deliver results. At least they did it with me :)

<snip>

> But, if those developers that write code do not
> follow standards, what good does this most important part of the design
> process do -- what does it accomplish?

Write a bug report. I am sure people will fix it, if they find the time ;)

<snip>

>
> http://home.earthlink.net/~tyrerj/kde/Improvements00.tar.bz2
>

Are you asking for a review for this patch? If yes, you are in the right list. 
Otherwise, file a bug report. Let's see what happens.

> I can write code, it is just that I feel that I am currently better at
> design work, and testing.  I think that some developers understand this.
>   But, this is not about me, it is about the fact that in a large
> project, design work becomes the most important part of the work and we
> all need to understand that.

KDE has a great way to avoid pointless discussions: the implementers decide. 

http://quality.kde.org/develop/policies/

You don't agree? So do something better. Note that this policy does not mean 
you can't argue and propose better solutions. ( I even wrote a report for an 
application in the past, and most of the issues I pointed out were solved. 
Note that at that time, I was writing its docs, and that helped). But you 
can't force people into doing something: you first have to convince them, and 
even if you do, they are free to implement (or not) what you agreed.

Another good example of non-"coder" design is OpenUsability effort. AFAIK, 
"coders" love the reports. Nobody force them to implement the changes, but 
they do.

If you can't code, write detailed bug reports, usability reports, mockups, 
docs, whatever. In my experience, this *works*. Well, at least most of the 
time.

> I also note that I feel that the example work that I have done is
> something that is currently very important to the KDE project.  There
> are a lot of similar small issues that need to be fixed.  This will,
> despite what some coders think, greatly improve the project.  Doing a
> lot of small improvements has a cumulative effect.

I completely agree. There are tons of these small issues in KDE. But you must 
have the nerve to accept refusals, to argue your point, and to modify your 
contributions following the maintainers feedback.

> My goal is to see KDE become a professional quality project.  To
> accomplish this we need the work of designers, testers, and bug
> reporters as well as coders.

I also agree. That's why it is important not only to attract talented people, 
but to do so in a way they don't get disappointed with how open source works. 
There are some limitations in our model, mainly paid people :) Therefore, all 
you can do is your best, you can't force anyone to do something for you.

Cheers,

Carlos Woelz