Managing the community information stream

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Managing the community information stream
Дата
Msg-id 200705060230.l462UFe23826@momjian.us
обсуждение исходный текст
Ответы Re: Managing the community information stream  (Dave Page <dpage@postgresql.org>)
Список pgsql-hackers
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. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: plperl vs. bytea
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Teach tuplesort.c about "top N" sorting, in which only the first