1,107
edits
Support/TikiWikiUpgrade: Difference between revisions
Jump to navigation
Jump to search
→Option 1
| Line 94: | Line 94: | ||
The forums are the slowest part of Tiki that we use (and we are the biggest users of same). In our research, all forum options are fairly awful, so we think we can do better and build in the features needed for a support-specific forum rather than a general discussion forum. | The forums are the slowest part of Tiki that we use (and we are the biggest users of same). In our research, all forum options are fairly awful, so we think we can do better and build in the features needed for a support-specific forum rather than a general discussion forum. | ||
Advantages | ===Advantages=== | ||
* We get the latest version of Tiki which has been through QA as a whole. I am not in favor of partial backporting of selected features. We've done this in the past, and it ends up taking a long time and causing regressions. | |||
* By contributing our work back to the community (both existing patches and future refactoring work) we both act as good open source citizens, and stay in sync with the Tiki development efforts, making future upgrades much easier. | |||
* By making a decision to reimplement/refactor parts of Tiki to be better we are freed up from the duct tape approach we have used in the past, and will also be making the base code a better product in future releases. | |||
Disadvantages | ===Disadvantages=== | ||
* This approach has more upfront work to get on to the Tiki 4.x branch. This would seriously limit the amount of SUMO specific work we could do in Q4. I would argue that this is effectively the start of the refactoring work, however, and at some point we need to spend time on refactoring. This approach front loads that portion of the work. | |||
* Tiki 4.x will have a new set of bugs so we will see a rise in issues at the beginning. | |||
==Option 2== | ==Option 2== | ||