KDE Usability Improvements

[James Richard Tyrer]

Carlos Leonhard Woelz wrote:
<SNIP>
> <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 ;)

Wouldn't it be better if developers followed the guidelines?

> <snip>
> 
>> http://home.earthlink.net/~tyrerj/kde/Improvements00.tar.bz2
>> 
> Are you asking for a review for this patch?

That would be OK, although my intent was just to show that I had the 
patch.  Actually, I would appreciate it if people would review the patchs.

> If yes, you are in the right list. Otherwise, file a bug report. 
> Let's see what happens.
> 
If needed, I will split up the patches and file bug reports.
> 
I have already filed one bug report:

http://bugs.kde.org/show_bug.cgi?id=104114

And, I attached a patch to: "kdelibs/kdeui/kstdaction_p.h"

to the report.  So, it was a bug that was already fixed.

The first thing that happened was the it was reassigned to KDE Artists. 
  I hope that that was just an honest mistake.

Perhaps there is a better way to submit such patches than to file a bug 
report.  Should I split it up and send the relevant parts to the 5 
maintainers?  Or, is there a Suggestion Box for such patches?

>> 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.

Something better is that it should be policy that the KDE Guidelines be
followed.

Another issue with this is that, in some cases, the most assertive nay 
sayer rules since it isn't going to a vote of the Core Developers for 
some small patch or bug issue.

> 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.
> 
Perhaps you have not had the experience of a 'Developer' responding to 
your suggestion by asking you to submit your patch.  To me, this is a 
really lame excuse.  So, now with patchs in hand, I will have to see if 
they come up with some other lame excuses. :-)
> 
>> 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.

Perhaps you can help get this started as an organized project.

>> 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.

As I have said, I feel that developers do not do enough to encourage new 
contributors.  In fact, some of them seem to go out of their way to 
discourage new contributors.  At the same time they complain that they 
need more developers.  Something appears odd there.

-- 
JRT