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

List:       kde-devel
Subject:    Re: Suggestion about a project workflow system
From:       Tom Albers <tomalbers () kde ! nl>
Date:       2008-06-27 15:57:37
Message-ID: 242920190.tGbl3TAnAW () kde ! nl
[Download RAW message or body]

Op vrijdag 27 juni 2008 11:53 schreef u:
> Some emails ago, someone said that using a project management tool means 
> duplicate the work for developers.
> 
> I'm sure that it is not true.
> 
> Developers, instead of keeping updated a plain text file, or whatever else 
> their are used to, should all use the same centralized system.
> 
> I hope that actually, for a good development, developers are doing this two 
> basilar things:
> - write down somehere what they plan (1)
> - track what they have done (2)
> 
> About (2) this is actually done directly on the SVN commit.
> 
> We need only a system for keeping the development plan (1) and when something 
> is done:
> - if this implements a planned feature, this will automatically marked as done 
> (there is the need of something which will connect SVN commits with the 
> development plan, something like it is done with BUG: # for closing bugzilla 
> reports);
> - if this implements a not planned feature, this will be automatically added 
> to the implemented features on the development plan.
> 
> 
> This will improve a lot the communication from devs to users.
> 
> 
> A good automation could be to transform wishes from b.k.o (when approved) to 
> planned features in the project management system. When this will be 
> implemented the corresponding "WISH" will be automatically closed.
> 
> 
> The correct workflow will be:
> 
> 1) users/devs/contributors can discuss about not planned features (in a way 
> that I'll explain at a later time). Call this discussions D1.
> 
> 2 (optional) ) When the discussion D1 has enough informations a WISH can be 
> added on b.k.o ( B1)
> 
> 3) if the new feature discussed on the first point is approved by developers 
> it will be added in the project management system (if needed, simply 
> confirming the wish B1). We can call this F1
> 
> 4) at a certain time one developer (or more) will implement the feature F1
> 
> 5) developer(s) will commits it and, while doing this, he will mark the 
> feature F1 as implemented. Automatically F1 will be marked as done and B1 
> will be closed.
> 
> A further automation could be to do a link from the initial users discussion 
> to F1, so all commenters of discussion D1 will be informed about the 
> implementation of F1.
> 
> 
> 
> Again, what do you (developers) think about this?
> I'm trying to analyze the question so I need a good feedback :-)
> 
> 
> Thanks again to all! :-)
> 
> 
> Regards.
> 

Hi, 

First of all I think it is great you guys are trying to find a solution for these \
problems. 

Although you outlined the system very well, I see some problems. The connection \
between F and D is fragile and should be done by the same system, as Ossi already \
indicated. Trac has this for example. You can schedule bugs and features for a \
certain release. 

It's probably the same as the changelog we use for the kde releases, it is man made, \
and we all agree that's a waste of resources. Basically there is just one \
core-problem and you want to have different 'views' on it to generated user parsable \
text for the changelog and for your overview.

Does anyone know if the next bugzilla can cover some of the current issues we have \
with bugzilla? I prefer to have just one tool that's scalable for all purposes. ( \
including review board )

Toma



>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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