Support/PlatformEngineering
Overview
We need to come up with 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.
The evaluation criteria are as follows:
- Is the new codebase easier to understand and develop further? That is, is it easier/more enjoyable for our webdevs to do their jobs?
- Can we get more done in a release cycle? This requires more than one release cycle, as the first one will be testing a new process.
- Is the new codebase more robust?
- Is the new codebase at least as performant as the old one?
Option 1: continue with Tiki
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 code
The outcome of the option matrix we developed in Q3 2009 ([[2]]) was that none of the other existing platforms look significantly better than TikiWiki. If we go down this path we would be looking at reimplementing SUMO from scratch.
When considering this option we should remember the pros and cons of porting to a new platform that we analyzed previously.