The Wiki TODO

• Update to latest version
  • Alter the RSS feed to show unified diffs instead of a page snippet
• Tweak layout/look some more (please everyone make requests!)
• Create a namespace guideline document and use |namespace templates (for example for the RFC's)
• Find some way to “encourage” people to write comments for their changes
• 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 (http://cvs.php.net/viewvc.cgi/pearweb/public_html/rest-login.php?revision=1.4&view=markup, 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 easily link mailinglist mails (especially internals). Proposed syntax is something like [[list:<message-id>]]
  • Macro to easily link bug ids. Proposed syntax is something like [[bug:<bug-id>]]
  • Macro to format user names. The macro should check whether the user has php-src commit access and visualize that accordingly

Already completed:

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