Re: Managing the community information stream - Mailing list pgsql-hackers

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