1. Make Tiki good enough (fix bugs, etc.) so that it can be released by the Packaging Team
2. Provide Documentation Team with basic information about features.
3. Update all Developer documentation to take into account new version number and features. Ex.: Download, Commit, Hello World, etc....
4. Review all Experimental branches and delete if appropriate (could be done at any time, but a 6-month reminder is good).

• DevTwoDogFood

• Semi-automatic merging period: handling them and deciding when to stop
• Fix bugs
• Add features
• Keep branches and trunk in a dogfood quality and "releasable on relatively short notice"
• SourceForge.net: Keep our space tidy there
• Keep up to date and useful all the developers documentation workspace at http://dev.tiki.org (while bug report & wish list triage is handled by the Wishlist Triage Team.)
• See Interaction with other communities below

• Clean-up review documentation for developers (intro for new devs)
• Migrate to Allura (changi)
• Cleanup
  • Endangered features
  • HowToDev
  • Migrate all relevant dev documentation in wiki page format on dev

• Keep list of included libs with version status (so at any give time, we know what could/should be upgraded)
  • http://sourceforge.net/p/tikiwiki/code/HEAD/tree/third_party/externals-to-composer-map.txt
  • http://sourceforge.net/p/tikiwiki/code/HEAD/tree/third_party/component_version_listing.txt
  • External Libs
  • Zend Framework (see ZF2 mappings)
• For security issues, an update may be warranted in the LTS versions with Security Team. Ex. ZF security updates can make it to 6.x if they affect our features. See Security Team
• For non-security issues, decide if we stay with old version or upgrade (ex.: just upgrade in trunk)
  • Deciding not to upgrade to latest version because the new features don't justify the effort is perfectly OK. Not deciding because we didn't evaluate is not OK.
• Be in touch with various projects for cross promotion (Tiki moved to Smarty 3, Tiki uses latest version of HTML Purifier, and thus, this should be indicated on their site)

Make sure the list below has a contact name for each (This list of names could also be maintained with version numbers)

• jQuery community (Jonny?)
• Smarty community (Stéphane?)
• Zend Framework community
• PHP community
• MySQL/MariaDB communities
• cclite software and their main developer (Xavi)
• R software and their community (Xavi)
• jCapture and their community (Marc)
• Kaltura. They requested a cleanup of our documentation page. Also, the special license exception needs clarifying. Also dogfood at tv.tiki.org needs to be decided/cleared up
• Google: Google Translation, Google Summer of Code, Chrome issues, etc.
• Microsoft Translations (Greg Martin & Pascal St-Jean)
• Clipperz + our community account (Marc)
• Piwik (changi?)
• HTMLPurifier
• CKEditor (Geoff?)
• elFinder (Jonny)
• jQuery.sheet (Robert)
• jQuery.s5 (Robert)
• OpenLayers
• PHPIDS (Integration on hold for now, but Marc is the contact)
• SabreDAV (not yet integrated, but is on roadmap)

  
  

• Wishlist Triage Team
• Continuous Integration Team
• Security Team
• Performance Team
• Packaging Team
• Bootstrap Team
• Later on, we may make teams by components (front-end, etc.) or by Use cases.

  
  

• Developer
• Developers Team