Questions

• Where will we coordinate work?
  • I think on themes.tiki.org
• Bootstrap 2 and later 3, or directly to Bootstrap 3?
  • Licensing issue prevents us use Bootstrap 2
  • There are several non backward-compatible changes
  • I suggest we shoot for compatibility with Bootstrap 3 to avoid doing a lot of work twice.
• What about LTS handling?
  • Option 1: start revamp after Tiki12 LTS
    • Benefit: We can do pre-requisites such as Menu Revamp
    • Benefit: So we have less work later, we can start with migration of some aspects like
      • http://twitter.github.io/bootstrap/customize.html#plugins
      • Some of the themes (ex.: we should have a FiveAlive for Bootstrap)
    • Benefit: We can start directly with v3
    • Benefit: Community has several months to get accustomed to Bootstrap
    • Benefit: No change on the schedule
    • Drawback: First LTS with Bootstrap will be Tiki15
    • Drawback: We could have started earlier
  • Option 2: start after 11.0 and try to finish for Tiki12
    • If Tiki12 isn't stable enough for a release on schedule, either
      • Option 2a) Retroactively identify Tiki11 as LTS
      • Option 2b) Identify Tiki13 as LTS
• Do we try to support Foundation as well?
• Will we still support the core/existing customisation approach that Tiki has - even with a Bootstrap theme (I'm probably showing my ignorance here! - Geoff) e.g
  • being able to take a standard theme but apply an 'option' (/styles/theme_name/options)that tweaks/adds different css etc., which includes:
    • option specific images
    • the Newsletter specific css
    • etc.
    • how will quirky browser tweaks be handled eg ie7, ie8 files etc
  • having a set of .tpl's that are theme specific (/templates) - with customised mail templates folder
  • be able to apply theme specific modules

Evolution or revolution?

Do we go for a clean break / "burn all bridges" approach and force major changes on all legacy themes? or do we make an effort to try to make old themes still work?

Arguments for clean break

• End result will be simpler code
• End result will be closer to what people already know (people that use Bootstrap that is)
• Most theme intense sites have more than enough features in the LTS versions and can use that until they decide to refresh their site design.

Arguments for legacy support

• Makes it easier for heavily customized themes to upgrade

Things to watch out for

Things that Bootstrap doesn't cover

• Logo?
  • Presumably, Tiki's HTML classes will be a superset of the Bootstrap classes, so our current method for specifying the logo can still be used, in combination with the benefit of Bootstrap's layout.
• RTL is not in v2
  • Licensing issue prevents us use Bootstrap 2 anyway
• Let's use http://schema.org/ when possible
  • I do not understand how do Schema attributes validate in HTML - luci
  • luci, I think the suggestion was to use them for element/class names, etc.

Things that Bootstrap overlaps with existing components

• http://twitter.github.io/bootstrap/customize.html#plugins
• jQueryUI
• jQuery Mobile

Pre-requisites

• Menu revamp
• Migrate more things to Smarty plugins
• New space /themes/ directory (but old way still works)
• Move all temp content to one place
• Layout switcher (from experimental branch)

In general

• This is a lot of work
  • True, but Tiki's templates and CSS really need a major overhaul anyway. If that happens in a way that can take advantage of the Bootstrap bandwagon (as long as we still have design flexibility), so much the better.

In version 3.0

• No set release date, but probably sometime in 2013
  • "As we've previously mentioned, v2.3 is our last planned release before moving onto v3 fulltime" - 2013-02-07
• Many changes in class names
• Dropping submenu support
• https://github.com/twitter/bootstrap/tree/3.0.0-wip

Workflow

• http://coding.smashingmagazine.com/2013/03/12/customizing-bootstrap/

Related links

• http://tiki.org/forumthread46596
• http://tiki.org/forumthread46597