Here's my idea of the zwiki roadmap for 2005 (posted 2005/01). Feel free to propose others.

Simon's 2005 Zwiki Roadmap

I resolved not to work on new Zwiki features in 2005. I may well accept them from others, but I won't do them myself. This is to focus (my) energy on refactoring, cleanup, polish, docs, and fixing "broken windows", and a quality push for 1.0. Feature work from others is welcome as ever. Tasks that are funded in some way almost always jump to the head of the queue and become priority no. 1, as usual.

  • clarify copyright strategy
  • research, choose single or multiple copyright policy
  • update license and copyright policy (cf LegalDepartment, CodeRepos)
  • document copyright & license status
  • document relicensing/remuneration policy
  • document contributor procedures
  • get development moving steadily again
  • publish roadmap(s)
  • publish quick timeline(s)
  • gather complete up-to-date contributor info
  • get tests working again
  • improve release automation
  • reduce patch response time
  • increase issue resolution rate
  • clarify/organize/understand community & product status
  • find a better way to survey zwiki sites
  • collect zwiki sites, users, statistics, testimonials, screenshots..
  • identify/support key sites (ubuntu, zopewiki, zwiki, zope.org, ..)
  • clarify use scenarios, user demographics, community priorities, alternatives
  • clarify product value, life expectancy
  • improve discussion process
  • simplify & clarify discussion alternatives
  • reduce all kinds of mail and wiki spam
  • improve signal-to-noise ratio on list and wiki
  • set up useful rss feeds
  • ensure sites and discussion forums are highly reliable
  • reorganize documentation, product components, issue categories
  • NewUsersGuide?
  • NewAdministratorsGuide?
  • NewDevelopersGuide?
  • separate out page types
  • archive/clean out old docs
  • separate/archive discussion
  • increase product quality and rate of development
  • clarify mission, goals, focus
  • improve reliability, reduce bug count
  • reduce complexity of features, setup, docs, code
  • improve encapsulation/componentisation
  • provide test coverage/stability/completion level guidelines
  • note development goals and a rough schedule
  • set up experimental open-access darcs repo(s)
  • attract more contributors, increase distribution of work
  • 1.0 release