Re: 8.2 features status - Mailing list pgsql-hackers

First, +1 on Josh B.'s point about trying out Trac, since it's  
already up and running. Josh D., can you just turn that on? (BTW, is  
trac linked off http://commandprompt.com anywhere? I had to google to  
find it yesterday...)

On Aug 9, 2006, at 11:34 PM, Tom Lane wrote:
> Mark Kirkwood <markir@paradise.net.nz> writes:
>> Robert Treat wrote:
>>> Wouldn't a thread reply saying something like "Bruce, can we add  
>>> this as a
>>> TODO with the following wording: blah blah blah"  likely suffice?
>
> That's pretty much how it's done now ...

Robert missed the point I was making... there is value in keeping  
track of ideas that may not have enough consensus to be a valid TODO  
yet, but could still be useful.

>> Yeah - and/or a patch to TODO or the relevant TODO.detail (I can't  
>> see
>> why that is hard or onerous). Plus it is seen by a wide audience,  
>> some
>> of whom might not be tracking any wiki (very likely if there end up
>> being several wiki's....)
>
> Yeah, the main problem I have with TODO-on-a-wiki is the question of
> quality control.  I've been heard to complain that "the TODO list
> consists of everything Bruce thinks is a good idea", but for the most
> part things don't get onto TODO without some rough consensus on the
> mailing lists --- at least about the nature of the problem, if not
> the exact shape of the solution.  I'm worried about a wiki having  
> pages
> that have not been peer-reviewed at all.  In some respects that  
> wouldn't
> matter, but what of our hypothetical newbie developer coming along and
> taking entries at face value?  If you don't know the project well  
> enough
> to recognize bogus entries, you could still end up wasting your time
> on silly ideas that will get rejected once seen by a wider audience.

Agreed... there needs to be enough consensus and 'critical mass'  
before something becomes an official TODO. Because of that, we  
shouldn't allow anyone to edit the TODO wiki (though I do think we  
shouldn't put the entire responsibility on Bruce).

A nice thing about a wiki is it makes it easy for people to  
collectively work on a use-case and design for a TODO item. One thing  
that could come out of this is the expectation that TODO items that  
aren't "inherently obvious" (however you define that) must come with  
X amount of documentation (use cases, design, what-have-you). This  
isn't something that should replace discussion on the mailing lists,  
but I think that being able to point to a wiki page with the  
finalized info about a TODO item is a lot better than pointing at  
list archives that are spread all over.
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461