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 <[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 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
