[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kuml-devel
Subject:    Re: Bad news
From:       flynn () lure ! u-psud ! fr
Date:       2000-10-24 11:33:38
[Download RAW message or body]

On Tue, Oct 24, 2000 at 11:54:17AM +0200, Baak, E.J.M. wrote:
> Hi Guys,
> 
> i'm sorry to tell you that Keith has requested me to take him off the
> project.
> 
> In short, Keith was having problems with the way things were going, he
> didn't have confidence that the req list would come to an end and was afraid
> that the projects light  would slowly dim.
> He did make some good suggestions though and i think i should mention these
> here:
> - first finish the requirements;
> - to do so, talk about one subject at a time, moderated by the team leader;
> - divide the project into two separate projects: one for the lib and one for
> the GUI part;
> - split up the team and have them work on one of the parts and let them
> communicate by separate mailing lists.
> 
> I must tell you that i have the same problems with kUML but i haven't come
> to the point of pulling the line so i guess you're stuck with me for a
> while.
> 

  Losing a developer is certainly unfortunate, especially one who has contributed to
the previous kUML code base.  I hope that with time we will be able to demonstrate that
we are able to organize this project in such a way that all contributors will feel
that their contributions are valuble and are bringing us closer to our goals.  At that
point perhaps Keith will decide to rejoin us.

  My plea to all of you is to be patient.  kUML is, in many ways, a new project.  We
have many new members, a new home, a new source tree, and a new approach to kUML.  
I realize that this may be hard to accept for those who have been contributing for some
time to kUML but that is the door that Darius and the others decided to open and there's
no turning back now.

  Since we are a new project, we don't know very well yet what works and what doesn't in terms
of organization and some things we're just going to have to learn by trial and error and that's 
going to take time.

  As for Keith's suggestions, I agree with many of them. 

  My own suggestions are the following :

1) Finish the requirements

  Definitely.  

  Its a little worrying to me that the version 0.4 document has now been out for over
48 hours and that no one has commented on it yet.  I realize that for many of us designing
and implementing is a lot more fun than thinking about requirements.  Still the requirements
document is important.  Once approved it will be a sort of agreement among us about the 
system that we are going to build.  So all of us are concerned by it.

  Do we need a moderated discussion on the requirements ? : I don't know. 


2) Define the top level architecture.

  This is another point on which all developers are going to have to reach agreement if we're
going to be able to work on the same project.


3) Planning/organization

  This is where we move from working sequentially to working in parallel, which is essential
for the project to succeed.  Everyone has different skills and interests and we need to organize
things so that everyone can contribute.

   Determine what needs to be done to make kUML.  Divide this up into subprojects and divide
the subprojects into tasks.   

  Some examples of subprojects might be:

  a) Refine the analysis
 
    Say by developing use cases.  I think that this would contribute greatly to the quality
    of the software we will be producing but I definitely don't want to wait until its done to
    start design and implementation.  I see two reasons why we should start concrete development 
    as quickly as possible :

    a) Once points (1) and (2) are done many things will be clear enough that we will be able
    to start implementing immediately.  (The uml module for example -- the OMG did the design for
    us).

    b) If we wait too long to get some code coming together, many of us are likely to get impatient
    and lose interest. 

    So my suggestion is that if some people have an interest in analysis
    that they work together on use cases which will serve as a guide during the later stages
    of development.  The use cases would also be important for documentation and testing. 

  b) Library design and implementation

  c) GUI design and implementation

  For the moment though I think we should keep the library and GUI together in one kUML project because 
the libraries first purpose is to support the GUI.  Perhaps the day will come when they could be split 
up but I don't think that day has come yet.

  I think that Sourceforge has some sort of task manager form for this sort of thing.  I haven't played
with it but it might be worth using.

  So for the most part my suggestions are similar to Keith's, if stated a bit differently.  On the other
hand I don't really think it would be a good idea to split up the mailing list at this point.  It seems
to me that one mailing list should be enough for a project of this size as long as the traffic doesn't 
get so high that no one can keep up with even looking at the messages.  No one is required to read every
single message if some are not of immediate concern.

  Gerard 

[prev in list] [next in list] [prev in thread] [next in thread]