[RkWard-devel] Time, development speed

[Thomas Friedrichsmeier]

Hi all,

I meant to write this mail some weeks ago, already, but it's just one of the 
things I never got around to do. The short version is: I won't be able to 
afford as much time to RKWard as during January and February. That's not all 
that much of a problem with four active developers working, but it means I'll 
have to reduce some of my workload, so I will have enough time to do the work 
that is needed on the C++ side. Some suggestions on this follow:

Development speed / stabilization:
A whole bunch of plugins have come in at a rather neck-breaking pace, 
recently. This is good, of course, but also I'm a bit concerned about the 
speed of development, ATM. My feeling is, that we should try to avoid 
creating too many new plugins just yet, and instead put in a phase of 
stabilization. That is, I would like to encourage you to focus on getting 
your new plugins into a "finished" state, and make sure to get them reviewed. 
The idea is to get most current plugins out of the "under_development" state 
before creating too many new ones, so as to stay closer to a "releasable" 
state (I don't think a release is particularly close at this point of time, 
but we'll have to worry about that eventually).

Specific suggestions:
1) Please place all your under_development plugins into 
http://rkward.sourceforge.net/wiki/index.php?title=Development_Status_of_Plugins . 
On this page, please indicate, whether you consider the plugin to 
be "finished", or whether you are still working on it. It may be a boring 
task, but I think the coordination overhead is well invested.

2) Please try to review some of the other plugins in under_development. I know 
it's not as much fun as writing new plugins, but actually, it's quite 
instructional to see how other are approach common problems in plugin 
writing. Also, my personal experience shows, it's much easier to spot 
problems in somebody else's plugin than in your own. Try to do a thorough 
review of two or three plugins, and provide feedback on the list. Don't be 
afraid of nitpicking, we need this to get good quality. Don't take the 
feedback you get personal (even if it is nitpicky). Making all sorts of 
mistakes is a normal part of the development process.

3) These are no strict rules, and of course, if you are close to finishing 
another plugins or two, it may be a good idea to focus on that, first, 
instead. However, keep in mind, that when creating several plugins of a 
similar kind, it may be a good idea to get some few of them reviewed, first, 
before copying the "bugs" to many further plugins. So concentrating on 
review, first, may actually save you some work, later.

Well, I hope I'm not taking away too much fun with this mail, and of course 
feel free to disagree / discuss this. This is just my feeling about our 
current development speed.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20070301/841ab09a/attachment.sig>