Migration Work High Level Overview

High Level Overview of Migration Work

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Jargon:

• Challenge Platform, henceforth known as "the Platform" - the open source implementation of the Redesign Challenge
• Redesign Challenge, henceforth known as "RDC" - the original implementation of the Platform with proprietary and exclusive content
• Internationalized/Internationalization/i18n/I18N - the process of taking language-specific text and placing it into translation files which allow the platform to support more than one language

Main contention and unification points:

• Content - all text strings must be in an internationalized form to make it easier to override and import custom strings.
  • Strings must be replaced with suitable I18N versions.
  • The EULA and Privacy Policy must support i18n.
• Configuration - all base-level configuration requirements must be documented. Any additional configuration beyond the base of the Platform must be documented in its respective project.
• Style and Design - Without encroaching on the integrity of the Platform's style, we must allow the existing styles to be swapped out for custom styles.

Proprietary Elements

• Images relating to RDC
• With respect to elements that depend on some form of third-party integration, such as Mandrill, Amazon S3, twitter, and GMail:
  • Elements that rely on our S3 instance pull down a huge list of schools and districts. Is it the case that we can release this data to the public? If not, we must identify core components of the system that depend on it.
  • Elements that rely on Twitter, such as the avatar uploader feature, are custom and should be opt-in. We should provide a recipe to add this functionality in, but we should not couple this so tightly with the Platform.
  • Save for critical registration flows, emails are strictly custom and must not be included in the base platform.
• Hooks in certain places of the code must be introduced such that added functionality can be introduced where the proprietary implementation is too closely coupled, such as the case with Embeddable.

Developer Support

• Migrate current setup of the Platform and RDC to use Docker to facilitate and simulate deploys. This is in support of the Platform not being able to actually deploy anything until it has been integrated with RDC.

Migration and Deploy of RDC

• Clean up the way the deploy on RDC is done. We presently have two remotes - one for staging and one for production - and two separate branches to denote these. This overcomplicates the process, and should be reduced down to one branch (master), and the two remotes.
• The Platform will be packaged into a gem. RDC must pull this gem in to it as a baseline.
• The custom elements as identified from RDC must be applied on top of the Platform, with the Platform being pulled in as a gem as previously illustrated.
• To facilitate the gem development, the application will become a mountable engine. This appears to give us the best opportunity to build something that is both standalone and extensible.