***BOGO*** Re: Suggestion about a project workflow system

[Tom Albers <tomalbers@xxxxxx>]

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