Define template classes

[chadwcarlson]

Proposal

Templates at Platform.sh serve different purposes. This issue involves defining classes that designate those different purposes, so that:

• users can easily determine a proper starting point
• templates can be appropriately documented for their use cases
• template maintenance expectations are better defined
• example projects provided by Platform.sh, and those provided by the community, are clearly distinguishable

Namespaces

Templates can come from two main namespaces, with two communities of owners:

• Platform.sh official: any template residing in github.com/platformsh-templates is a member.
• Community templates: any template registered through github.com/platform/templates-external is a member. Ideally, in console, any community template card will have a Community label on that card when a member.

Classes

Within Platform.sh official templates, we wish to designate X different classes of templates:

• Starter
  These templates are meant to act as starting points. A user deploying a particular framework could use the changes made to that framework's upstream code to migrate their own application to Platform.sh. A user could also follow the template generation steps used in template-builder to quickly put together a project deployable to Platform.sh (Quickstart tutorials). There may also be a subset of Starters with a Priority to them, reflected in additional documentation, support, and attention outside of just the templates project.
• Demo
  These templates are meant to act as reference for more advanced applications, especially to those changes made to frameworks in the Starters class. It's unlikely that the repository would be exactly copyable for that users migration, but understanding how that demo works will better equip them to implement something similar in their own project.
• Experimental
  These templates can act as starting points or reference demonstrations for the user. The only difference between Experimental and the other two classes is attention given to its maintenance. A new template request would be added to this category, but until more detailed migration documentation is added alongside that template, it cannot be considered a Starter, for example.
• Deprecated
  A member of any previous class whose functioning depends on a piece of infrastructure approaching EOL.
• Archived
  A Deprecated template that has gone EOL. These templates remain available on GitHub in read-only form for future reference, but no longer receive updates.

There are two additional classes that are not yet included in template maintenance, but may be at a later date:

• Off the shelf
  Meant to designate templates that the end user may deploy, but is unlikely to develop directly aside from dependency and infrastructure updates. This could include large applications like Mattermost or custom services like Meilisearch.
• Workshop
  This is an advanced case of Demos, where instead of merely demonstrating deployment, configuration, and inheritance, the user is meant to follow a series of documented steps to work with the end application. These types of projects can be useful for in-person/online workshops, onboarding, and a future LMS.