Support/PlatformEngineering: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(category -> Support Archive)
 
(15 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Draft}}
= Overview =
= Overview =
We need to come up with a plan for engineering a sustainable platform for SUMO.  The goals are:
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 SUMO code platform quality to
** Increase robustness and performance
** Increase robustness and performance
** Increase developer happiness
** Increase developer happiness
** Reduce time to implement new features
** Reduce time to implement new features


= Tiki Upgrade =
= Tiki Evaluation =  
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]].
[[Support/PlatformEngineeringTikiEvaluation]] discusses our evaluation of TikiWiki 5.1 as a possible future development platform.  We arrived at a decision to rewrite the SUMO platform from scratch.
 
= 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? 
* Is the new codebase more robust?
* Is the new codebase at least as performant as the old one?
 
I recommend undertaking at least two release cycles, before performing a formal evaluation.  This 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 I feel cannot be done 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 and more awkward.
 
= 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 [[https://wiki.mozilla.org/Support/TikiWikiUpgrade]]).


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 ([[https://spreadsheets.google.com/ccc?key=0Ao5KB_TZOvbVdDgtSEdRNnNyeDBvWUtJOUZYZnU0Rnc&hl=en]]) was that none of the other existing platforms look significantly better than TikiWiki.  That means that this option represents reimplementing the platform from scratch.
= Kitsune =
[[Support/Kitsune]] is our project to reimplement SUMO.


When considering this option we should remember the pros and cons of porting to a new platform that [https://wiki.mozilla.org/Support/TikiWikiUpgrade#Port we analyzed previously].
= Frameworks =
[[https://spreadsheets.google.com/ccc?key=0Ao5KB_TZOvbVdGhxNVlad2YxSW55Qy1wRnhWZmhJX1E&hl=en Framework Matrix]] looks at possible languages and frameworks for building the new SUMO.


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.
[[Category:Support Archive]]

Latest revision as of 09:13, 14 July 2021

Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly.
If you have any questions or ideas, please add them as a new topic on the discussion page.

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 SUMO code platform quality to
    • Increase robustness and performance
    • Increase developer happiness
    • Reduce time to implement new features

Tiki Evaluation

Support/PlatformEngineeringTikiEvaluation discusses our evaluation of TikiWiki 5.1 as a possible future development platform. We arrived at a decision to rewrite the SUMO platform from scratch.

Kitsune

Support/Kitsune is our project to reimplement SUMO.

Frameworks

[Framework Matrix] looks at possible languages and frameworks for building the new SUMO.

Retrieved from "https://wiki.mozilla.org/index.php?title=Support/PlatformEngineering&oldid=1236647"