Support/PlatformEngineering: Difference between revisions
< Support
Jump to navigation
Jump to search
No edit summary |
|||
| Line 7: | Line 7: | ||
** Reduce time to implement new features | ** Reduce time to implement new features | ||
= Refactoring = | = Tiki Upgrade = | ||
As [[https://wiki.mozilla.org/Support/TikiWikiUpgrade|decided]] in Q3 2009, Q1 2010 will be occupied with getting SUMO running on Tiki 5.1. We have both a [[Support/TikiUpgradePlan|high level plan]] and a [[Support/TikiUpgradeImplementation|detailed implementation plan]]. | |||
= Evaluation = | |||
= 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: | 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 | * Existing poor code quality and/or fragility | ||
* Impact of refactoring: choose areas that will have the biggest impact for users and developers | * 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 | * 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 Q3's option matrix () 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. | |||
Revision as of 16:19, 20 January 2010
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
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 Q3's option matrix () 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.