[RkWard-devel] Time, development speed

[Stefan Roediger]

Am Donnerstag, 1. März 2007 17:49 schrieb 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).
>

Consent. The plug-ins I created have a common structure. This is intentional 
and has the advantage that one bug, if existent, can easily be found in the 
others too. At least for me I plan to slow down and start fixing open issues.

> Specific suggestions:
> 1) Please place all your under_development plugins into
> http://rkward.sourceforge.net/wiki/index.php?title=Development_Status_of_Pl
>ugins . 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.
>

Consent.

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

Don't worry. Still fun here. This is a very important part and I take it 
serious because this tool is intended for serious purposes.
I'll slow down.

> Regards
> Thomas