On Sat, 2008-09-27 at 16:35 +0100, Michael Roberts wrote: > I would keep them in the tracker too. the question in my mind is if > dumping a large list into a single issue scales? Perhaps by > convention if an issue contains a list, it is considered a bucket and > people break issues out on their own as they go? A single issue with > 100s of comments is going to get a mess. but then you have comments > on issues in two places. that would be where the wiki would help as a > dumping ground for lists, where you could delete items on insertion > into the tracker. I'm just thinking out loud... I implemented the > full screen but marcus beat me to it. i'll start at the bottom next > time ;) > > just my 0.02 GBP / EUR
I'm not for a wiki page beside one that explains how to deal with tickets. This page is already there. As long as you cannot group tickets with assigned dependencies a ticket with 100 issues is not a good idea. Just create 100 issues where discussion takes place in every single issue. I don't see a single reason not to do so. Everything else is too complicated. Keeping information in two different places is a no no. If there is something more complex that has to go this way it is milestone planning. So you create a wiki page with all the issue numbers that have to be solved before the milestone is reached. Usually you would expect this from the tracker, too. But google code is not capable of doing this. In this case the wiki page does no harm as it is easy to sync. Just have a look at the tickets and you know what to do. I want to avoid new categories or types in the tracker as well as it just complicates things. If you need a strong filter for dealing with the tickets it is ok. that's another 2 cents (euro type) Norbert _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
