Support/PlatformEngineering

This is a DRAFT ONLY.

Overview

This document is a plan for engineering a sustainable platform for SUMO. The goals are:

• Evaluate the updated Tiki platform for suitability as a codebase that can continue to grow and improve with SUMO and with other projects using it for support
• Improve code platform quality to
  • Increase robustness and performance
  • Increase developer happiness
  • Reduce time to implement new features

Tiki Upgrade

As [[1]] in Q3 2009, Q1 2010 will be occupied with getting SUMO running on Tiki 5.1. We have both a high level plan and a detailed implementation plan.

Evaluation

In Q2 2010 we will develop our first releases based on top of TikiWiki 5.1. This will enable us to evaluate the success of our upgrade.

During the first two release cycles we will gather data relating to the following objective and subjective indicators. In mid-May stakeholders will meet to make a decision about the future development path for SUMO. This decision should be influenced by objective factors but will need to take into account developer skillsets and internal culture.

The evaluation criteria are as follows:

• Is the new codebase easier to understand and develop further than the old one? That is, is it easier/more enjoyable for our webdevs to do their jobs?
• Can we get more done in a release cycle?
• Is the new codebase more robust?
• Is the new codebase at least as performant as the old one?
• Is the new codebase actively good on each of these criteria, as opposed to just better than before?

The recommendation to undertake at least two release cycles before performing a formal evaluation is in conflict with the desire to move forward as quickly as possible with the eventual decision path, however it is important to make a good decision here, which cannot be done objectively with only a single cycle. The first new release after the upgrade will be testing a new development process. Doing anything for the first time will be slower.

Option 1: continue with Tiki

One of the rationales for upgrading Tiki to current was to enable us to rewrite parts of the code as we see fit. This includes improving existing sections of core code and modules.

Refactoring

We need to identify which parts of Tiki we plan to rewrite or refactor. The criteria for choosing these are as follows:

• Existing poor code quality and/or fragility
• Impact of refactoring: choose areas that will have the biggest impact for users and developers
• Ease of refactoring: While this would never be the only criteria, there is certainly value in choosing low hanging fruit

Option 2: Redevelop SUMO platform

In Q3 2009 we discussed three options: Upgrade, Fork, or Port (see [[2]]).

Having done the upgrade, there is really no point in forking the code as any changes we make are trivial to upstream. The outcome of the option matrix we developed in Q3 2009 ([[3]]) was that none of the other existing platforms look significantly better than TikiWiki. That means that this option represents reimplementing the platform from scratch.

When considering this option we should remember the pros and cons of porting to a new platform that we analyzed previously.

In addition, while developer morale and retention is a current reason for moving away from TikiWiki, having the previous six months' work discarded quickly will likely not improve morale. Having committed previously to the upgrade path, the consequences of now moving away from that path must be considered.