PersonalRoadmapForSvenDowideit

Wow, this topic is old. I should update it more often.

My goal is to be an obvious and significant resource in the development of the TWiki Core. I currently work as an independent consultant, as this is so far, the only existing way for me to be able to spend as much time on TWiki Releases and TWiki Features.

Right now (August 2008) I am working on a conversion from a live TikiWiki, and in the process am working on increasing the integration between TWiki's SEARCH and external Search engines - an initial experimental demonstration using SearchEngineKinoSearchAddOn/ is in svn, awaiting TWiki 4.2.2.

When I have time, I update the TWikiInstallers for Debian, Redhat, Windows and OSX.

In the coming months, I have a large backlog of FeatureRequests to work on - though I'll be looking for more paid work to continue being able to spend time on it.

Old Summary

• TWikiInstallers
  • re-examine an upgradeTWiki script / tool - It will become vital for all of the TWikiInstallers
• general UserMapping work - OpenID, Joomla, Trac,
• advanced UI, Web, User oriented tools, focused on creation and development of content.
  • TopicObjectModel -
  • InlineEditPlugin, ComponentEditPlugin, WikiwygContrib - advanced sectional mini-editors
• flexible scalable TWikiApplication engine, with deployment and configuration tools
  • these tools should be able to be written as TWikiApplications
• a real workflow system
• decent OO, with a minimalistic TWikiKernel
• a community driven process, with no requirement for Core teams or Roles, other than TWikiJanitor (the poor bugger that needs to have final root access to the server)
  • DEVELOP is the vehicle that this was developed on for DakarRelease, and now we're renameing that to be more obvious

results I hope to enable

• finish the modularisation of the UserAuth & UserInfo module (UserDotPm), implementing a JoomlaUser (done for limited release), OpenID, PAMUser and WindowsUser
• continue the development of TWikiStore modules - SvnStore, DBIStore, DistributedStore
• move these implementation classes into a ObjectOrientedTWikiPluginSystem
• add functions to BugsContrib

More general ideas

1. reduce the distributed docco & create Web based configuration and setup
2. refactor the content on twiki.org
   • create seperate webs for each release (Athens, Bejing, Cairo, Dakar) and move topics for each functionality / discussions into the appropriate webs, freeing up the namespace for future use (eg, there might be a RegistrationChanges topic for each version, detailing the changes / ideas specific to that version)
3. continue UpgradeTWiki
   • redo UpgradeTopics using the Store API, allowing upgrading from SVN

DevelopBranch needs

• a fully automated build system, that spits out TWikiKernel, TWikiRelease, TWikiDistros, TWikiPlugins
  • see DailyBuildAndSmokeTest - DONE
• a fully automated testing system that runs all the unit tests whenever there is a commit (or similar), and sends out rude emails to all people with commit access when there is a failure
  • DONE - once a night, to not load the svn server too much
  • http://develop.twiki.org/users/develop/pub/TestOutput/runtest.html
• DEVELOPer's to ensure that there are tests for any work they do (the only IronFist for DEVELOP)

I want the TWikiCommunity to not be dependant on the TWikiCore group. I want to see what TWiki becomes without the strong controls we have now.

-- SvenDowideit - 2004->2008