To follow up on this, if you look at how TODO items are created, they often come out of discussion threads, and sometimes more than one idea comes from a discussion thread. If we moved to a trackers system, how would we handle that?
Also, if I want to discuss renaming something or cleaning up some code, do we create a tracker item for that or do we have a developer email list to discuss such issues? And if we have a developer email list, how do we make sure everything that happens there gets into the tracker if needed? Basically, right now, the steam ignores non-TODO items that are discussed, while with a trackers, I am afraid you have to explicitly mark every discussion thread as uninteresting/closed, and I am worried about the manpower and participant overhead of doing that. --------------------------------------------------------------------------- bruce wrote: > Let me give you my approach to tracking. It might help set the stage > for moving forward. My goal has always been to foster discussion and > pull as many TODO items and patches from the discussion as possible (and > others do that as well by saying "Please add to TODO" or applying > patches). > > I see the process much more as pulling things from a stream of data, > rather than tracking every event. We already record everything in the > archive. The current discussion is how and who should summarize/track > that information. > > Right now, the TODO list is a good summary, and URLs help to give > detail. I am not sure seeing all treads of a TODO item would help. In > a way, the summarization is more valuable than the details for most > people. Again, the question is what is the cost of summarizing the > stream at a more detailed level vs. its value. > > Because I see us operating on a stream, it is unclear when to > pull an item from the stream and track it off-stream, such as in a bug > tracker database. I am also concerned that tracking itself not inhibit > the volume of the stream, particularly if discussion participants have > to do something more difficult than what they do now. > > The idea of the patch number in the subject line works with that > streaming model because it merely marks streams so they can be grouped. > The defining event that marks the stream is a post to the patches list. > We already number posts to the bugs list, so in a way we could improve > tracking there and somehow link it to TODO items and patch submissions, > but because many TODO items are not the result of bug reports but come > out of general discussions, I am not sure tracking would work as well > there. And what about features? Do you start assigning numbers there, > and what is your trigger event? In my opinion, as you start trying to > place more structure on the stream, the stream itself starts to degrade > in its dynamism and ease of use. To me, that is the fundamental issue, > and risk. > > I think a lot of this relates to the volume of work we do per > participant. I think we are probably near the top for open source > projects, and while more detailed tracking might help, it also might > hurt. > > I am hoping the "stream" analogy might help people understand why we do > what we do, why we are so successful, and how we can improve what we > currently have. > > -- > Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
