Re: Managing the community information stream

Bruce Momjian wrote:
> 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?
> 

We have the discussion on list, if it warrants a todo, we create a todo.


> 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? 

In the most conformist sense yes, but I can tell you that generally 
isn't how CMD does it. How we general do it, is to create a ticket basic 
on a topic, that ticket cc's a mailing list and discussion happens in 
reply to that cc. So the workflow doesn't actually change. Once 
everything is decided we may update the ticket with the final solution, 
and then when the work is done we close the ticket.

However, we do it the way we do, because we don't have email 
integration. Supposedly (which a small group is currently reviewing) BZ 
3.0 does have email integration so this may change a bit.

> And if we have a developer email list, how
> do we make sure everything that happens there gets into the tracker if
> needed?

See above.

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

Oh good lord, yeah I wouldn't want to do that either. Email is obviously 
going to be the predominant medium of communication. I think what would 
end up happening, if we were able to tightly integrate with email and bz 
would that at some point all discussions die off, it would be up to the 
person that opened the discussion or an bz admin to close or change the 
status of the ticket.

The nice thing is if someone comes back to the thread at any point 
(which happens all the time) the ticket should automatically re-open.

Joshua D. Drake


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