Introduction and a couple KDE quality comments/suggestions

[Zac Hansen]

My name is Zac Hansen.  I'm an experienced UNIX/Linux software developer 
with some KDE experience, but I'm just trying to get back in the fold.  

My contributions to KDE include when you go into keyboard shortcuts, you can 
double click on the event you want to set a shortcut for and it pops up 
the shortcut window (you used to have to select the event then push the 
buttons at the bottom.  Also, I wrote the code for stealing shortcuts if 
you try and use an assigned shortcut elsewhere.. alt-tab for example.  It 
will come up and ask you if you want to reassign it to the current event.  
(I think that's my code?  patch was originally rejected, but now there's 
functionality exactly like what I wrote.. so I'm taking credit for it :)



First, I think it would be nice to have a kde-quality chanel on irc 
(#kde-quality ?)  It would be a good place for developers to go if they 
have something they would like to see done.  They could post it to the 
mailing list and go to #kde-quality to see if there's anyone there to take 
it on.  It would also be a good place to interactively answer questions 
about what needs to be done.  Though if no one was going to hang out 
there, it would be worthless..

The second thing i that only half the problem with doing KDE development 
work is the learning curve on the technical aspect.  The other half of the 
problem is the learning curve on the organization of KDE.  Right now, even 
though I want to work on something, I don't know *what* to work on.  A 
concrete list of things that need to be done that are simple enough for me 
to do would be VERY helpful.  Possibly even some sort of 3-level 
organization scheme.. beginner, intermediate, and advanced or something.  
These would be relative to expected kde-quality skill levels and not 
related to full kde developer skill levels.   beginner would be something 
like "get this program, get this document, learn how to use this feature 
and write about it."  That would get someone all the way through getting 
unstable (or stable..), finding the document, learning a feature, possibly 
contacting the developer, and writing some docs.  Intermediate could be 
something having to do with a little more code or documenting a 
significant chunk of a program, while advanced would be full bug hunting 
or documentation of an abandoned or completely undocumented program.  

I just really think it's important to have a up to date list of concrete 
examples of things that need to be done, especially for people just 
getting started.  KDE can be very intimidating.

--Zac