1,107
edits
Support/PlatformEngineering: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
= Overview = | = 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 | * 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 | * Improve code platform quality to | ||
| Line 13: | Line 13: | ||
= Evaluation = | = 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. | 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: | 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? | * 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? | * Can we get more done in a release cycle? | ||
* Is the new codebase more robust? | * Is the new codebase more robust? | ||
* Is the new codebase at least as performant as the old one? | * 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 = | = Option 1: continue with Tiki = | ||