Re: Managing the community information stream

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

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +