Roadmap Discussion

Some of the content was refactored to here from the ReleasePlan topic

Introduction

With the recent event, it is important to have the following short term goals, to ensure that...

• the project keeps its momentum in the community and media
• existing users benefits from the fork on support questions and backward compatibility of extensions
• new users are correctly informed and feels welcome to changes
• stay focus as a community for a better future

In the short term (< 6 months), our position should be stabilised by continuous minor releases (including patches). Every T* users and developers would have integrated into the fork.

In the long term (> 6 months), the fork must have a bold statement to the FOSS community. The following should be met,

• corporate/organisation/user-centric approach
• lower barrier of entry for users and developers
• improved usability and interaction between user and the fork
• improved scalability and performance

Development should go in parallel, which has always been. Priority should be on the long term goals.

Short term

The current press releases put pressure on both T* and us. So our short term goals must be executed in manner that doesn't give any hint to others of any new shortcomings that wasn't in T*.

What has been a good impression,

• community support through blog posts, comments and donations
• media support for FOSS instead of commercialisation of FOSS
• quick establishment of twikifork.org/foswiki.org et al
• establishment of a legal entity for the fork, ala Association
• accurate information that ensures new and existing users are informed

The short term challenges are,

• rebranding in source code and templates (see RebrandingPlan)
• support existing installations from the rebranding
• bug fixes
• community focus and keeping up the momentum

The fork should ensure, in the next 6 months or more, the above challenges are met. The release cycle should be every 2-3 months.

First release

• Get VirtualUpgradingParties excited!
• Rebranding of T* (see RebrandingPlan)
• Deprecation notices
• Bug fixes

Second release

• New (core) popularity extension (aka POPCON)
  • Mimics popcon that we may know which are the popular plugins that needs to be part of the core in our major release
• Deprecation notices
• Bug fixes

Release numbering

If we stick with the current T* release numbers, we will soon create confusion for our users between TWiki.org releases and Foswiki releases. For instance: we make release 4.4, and TWiki.org a 4.5. How is this still compatible?

It would be clearer to reset the numbering to 1.0, 1.1, etc.

Following the 4.2.4 and on release numbering gives a better message that WE are the original project - just with a new name

This is a difficult decision.

Long term

A lot of work is going into the core that overall boost the fork. Lots of work, particularly testing is still needed. Key individuals who works in these specific areas should keep focus on the long term goals to meet the deadline. Long term goals should be set as priorities for key developers immediately after the first release.

The release should be after 6 months from now. We must ensure it's a rock solid major release that makes a difference in the press!

Corporate/organisation/user-centric approach

To ensure we understand who our market is and how we can continue to improve this OSS for them.

POPCON

Harness what we have gathered from POPCON. This should be an ongoing effort to understand which extensions should be part of the core.

Depending on the gathered information, Extensions should give priority according to the rankings. Pushing extensions that are popular up high, instead of having users digging deep.

Note it is not a requirement, but could be an interesting effort.

Examples of such extensions,

• FindElsewherePlugin
• WhateverTheNameIsForDiffAndHistoryPlugin
• PreInstallNatEditContrib

Improve usability and interaction

See UserExperienceHub

Questions,

1. Am thinking it's related, but would it include unicode/utf-8 support particularly in the source code? What's the status of unicode/utf-8?

Lower Barrier of entry

This is not entirely a major issues in T*, but there are rooms for improvement!

• Better structured documentation (See DocumentationTaskTeam)
  1. Admin documentation
  2. User documentation
  3. Developer documentation
• Demo of wiki applications

Improve scalability and performance

Goes without saying, as it is work from T*. It should include the following,

• ThinPrefsProposal
• EnginesAsContribs
• MultiStoreRefactor
• FoswikiCache

Make the project truely world wide by resolving the I18N issue.

• Support for UTF8 is essential. We need to decide if this goes into 4.3 or wait for 5.0. Or maybe we need a 4.4 which THE UTF8 release.
• Support for languages as contribs needs to be polished
• Support for languages in extensions is required
  • extensions must be able to publish their own language files
  • translations for extensions must be contributable without reference to the original extension author e.g. by editing a topic on n.o