The Wiki TODO

• Tweak layout/look some more (please everyone make requests!)
• Create a namespace guideline document
• Guidelines for moving wiki pages. Research plugins to allow all users to do it, in order to preserve edit history
• Add captcha as well as a required field for people to explain why they want to register
• Add PEAR login as a secondary auth fallback for pear (pear.dev karma should give full access to the pear namespace)
• Figure out exact wiki access permissions at login time based on http://davephp.net/karma.php (http://davephp.net/avail.gen.phps)
• Switch to reST as the wiki syntax
• Add some more Macros (http://wiki.splitbrain.org/wiki:interwiki)
  • Macro to format user names. The macro should check whether the user has php-src commit access and visualize that accordingly
• Discuss adding polls through the wiki

Already completed:

• Macro to easily link mailinglist mails. Syntax is something like [[list@<message-id>]]
• Macro to easily link bug ids. Syntax is something like [[bugid@<bug-id>]]
• Update to latest version
  • Alter the RSS feed to show unified diffs instead of a page snippet
• use |namespace templates for the RFC's
• Find some way to “encourage” people to write comments for their changes
• To :start or not to :start, for root pages, that is the question
• Implement support for magic PHP.net cookie
• Prevent people from picking the same nicknames on the wiki as are already used on master.php.net
• Fix self registration

Probably not going to happen:

• Move to CVS for storage file storage
  • Read meta data about last change out of CVS/Entries file
  • Use cvs.php.net for history/diff viewing and CVS commit mails, alternatively have a cronjob to keep meta data alive on the wiki, so that we can keep RSS feeds ..
  • Move away from pessimistic locking to optimistic locking only
  • Figure out a way to store different namespaces in different CVS locations (RFC's in one place, Upgrading guides in php-src etc.)
  • Figure out a way to select the right branch to commit to and to display. Probably we should always commit to HEAD and MFH to all active branches (which will be configured on a per namespace basis).
  • Commit mails should be directed to specific mailinglists on a per namespace basis.