Tom Lane wrote:

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.

To bring up PHP again:

This is the todo list for the upcoming 5.2.0 release that is currently in RC1. Most of the todo items in PHP do not need much detail, so this list does not carry much more information than Bruce's list. The wiki has support for ACL's, so I have given various trusted people direct access. Some developers however rely on me for updating the items.

As you can see there is a confirmed (as in the release manager has oked the todo) and an under discussion as well as a future 5.x release section. We already have a separate todo list for php 6.

A todo list that illustrates the ability to attach more information for a given todo item is my PEAR::MDB2 list in the same wiki:


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

Reply via email to