In Attendance

• Steven Burch
• Giulio Gratta

• John Baldwin

• Braden MacDonald

• Felipe Montoya

• Nimisha Asthagiri
• David Joy

User stories

Stanford

• Look and feel
• Feature development
  • Hiding, replacing, adding features
  • Adding disclamers
  • Adding HTML to sidebar, header, footer
• Have their own instances, each individually branded.
• Three separate prod deployments:
  • On campus instance
  • MOOC offering
  • Med school instance
  • Always the same platform code
  • Customizations are feature flagged
  • Use theming to hide SSO accounts tab
• Can't use the word "student" in some instances, for instance.
• SSO exclusively, no unlinking accounts
• Fork the platform
• One repo for all themes
• Fork of pattern libraries
• Ginko

Appsembler

• Customers: tech companies and education resellers
• Multi-tenancy
• Enterprise customers with standalone instances.
• Look and feel
• Need look and feel consistency with external environments
• Fork of platform, different branches for different needs (multi-tenancy vs. Enterprise)
• Enterprise share same branch and use feature flags
• Upgrades are horrible pain.
• Want plugin architecture, been thinking about their own.
• Figures
  • Need customization on frontend
  • Need custom cards/UI elements
  • Brand new code
• Email formatting is hard

OpenCraft

• Does not fork platform.
• Customizations done as theming, plugins, or features which get contributed back.
  • Limits their ability to do detailed theming, have to say 'no' sometimes.
  • Template overrides
  • CSS
  • Use translation files to change phrases.
• Dozens of instances, very easy to upgrade/maintain.
• Want better theming, still without customization/forking.
• Want plugin architecture
• No multi-tenancy
• Want real-time theming
  • Client uploads logo, sees it immediately for instance.
• Email formatting is hard
  • Nimisha says: Maybe better in Ironwood?

eduNEXT

• Three types of instances
  • Customized instances for people in their own data centers/AWS accounts
    • Big customers, very opinionated
    • Code lives in fork.
    • Try to use theming if they can, otherwise change code.
  • - Multi-tenant instance with 3000 sites
    • Use theming to make them all look different
    • Microsites used to change feature flags per client, add custom CSS, etc.
    • Site configurations change themplate path and swap themes for each customer.
  • Consulting for large projects. Super customized. Example: replace ecommerce with something else.
• Different types in different forks.
• 60 features added.
• Don't merge back.
• Every few months, take what's on Hawthorn master and build their features on top of it.
  • Extensive doc on how to do this.

General comments

• OEP process: be more communicative
• Why react? Wide adoption, Facebook adopted React, not bleeding edge, but solid and meets business needs.
• Need to communicate timelines for deprecation. Juniper? Later? Need to know far enough in advance that it's not a surprise and there's time to update/adopt it.
• Feature flags for each of the micro-frontends is a good thing.
• Don't want to rewrite themes with every named release.
• Pattern library: just kill it! Put styling somewhere else.
• Start getting down to brass tacks with practical proposals for customization - move on from requirements gathering.
• If devstack looked different than edx.org, many upgrade problems would be fixed.
• "Make the common case fast, make the uncommon case possible."
• Page that is a particular theming pain point? Dashboard.