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 <bruce@momjian.us> http://momjian.us
> EnterpriseDB http://www.enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +

--
Bruce Momjian <bruce@momjian.us> 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