Re: Managing the community information stream

To follow up on Andrew's idea of tracking things back to the TODO or bug
number:

We could have a universal developer number, something like PGD#23432 as
a PostgreSQL Developer number. We could assign them for submissions to
the bugs list, where we already assign a number. I could easily add
them to TODO items that already don't have a number from the bugs list,
and we could use the number for postings to the patches list that again
don't already have a number. (The PGD numbers would have value ranges
assigned for specific uses, like 0-100000 are bugs, 100001-200000 are
assigned as TODO items, +300000 are patches, etc.)

The idea is that if you are working on a TODO item you mention that
number in the email subject discussing it, and for postings to the
patches list. A web application could then read from the email stream
and pull out information about any item. The only overhead is people
mentioning the assigned number consistently.

One problem is that our development isn't linear --- often TODO items
are the result of several email threads, and TODO items are split and
merged regularly, meaning that a PGD number could be partially complete
or be merged with another number. When this happens, the number might
cause confusion, and I don't see a way to fix that easily.

---------------------------------------------------------------------------

Dave Page wrote:
> Bruce Momjian wrote:
> > 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.
>
> Bruce,
>
> I cannot really add to that except to say that you neatly summarized
> what I've completely failed to in my last few emails to Andrew. I agree
> completely.
>
> Regards, Dave.

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