WIP: Add GitLab.com plans as products to the comparisons.yml file.

Starting #1446 (closed).

This MR adds the GitLab.com plans to the comparisons.yml file so it can be used to generate the gitlab.com plans page automatically.

You can mark features as supporting specific GitLab.com plans as follows (don't include the comments):

- title: "Time tracking"
  description: "Time Tracking in GitLab lets your team add estimates and record time spent on issues and merge requests."
  link_description: "Learn more about Time Tracking"
  link: https://about.gitlab.com/features/time-tracking/
  # Free plan
  gitlab_com_free: false
  # Bronze plan
  gitlab_com_bronze: true
  # Silver plan
  gitlab_com_silver: true
  # Gold plan
  gitlab_com_gold: true

Once we have the GitLab.com plans fleshed out in the YML file I can put together an automatically-updated page like the Products page.

One sidenote: There's already a gitlab_com product which is used to compare GitLab.com to GitHub.com and BitBucket.org. Don't confuse that for the plan products. I'm not sure how we should handle the separation of those.

cc: @mydigitalself

changed the description

mentioned in issue #1446 (closed)

@connorshea would a simpler way to do this not be to have

gitlab_com_plan: free gitlab_com_plan: bronze gitlab_com_plan: silver gitlab_com_plan: gold

if the key doesn't exist, then it's not displayed. if it's free then it displays for all levels, etc...

That way we reduce the amount of data in the yaml, which seems neater. It may add a little more complexity to the rendering logic, but keeps the input data more concise. there's no case where something will be bronze and not silver for instance.

@mydigitalself that'd work, it'll require a bit of custom logic but nothing too bad.

@mydigitalself I think that for the majority of features on GitLab.com the bronze maps to EES, silver to EEP, etc. Can you think of a way to encode the information in features.yml that doesn't repeat or contradict this information? For example: when a feature is not relevant to GitLab.com hide it with a gitlab_com: false and otherwise infer everything for the EE tags?

@sytses I can't think of anything immediately that would break that mapping, however doing it with gitlab_com_plan does give us the flexibility in the future if we decide that a particular feature should be free on .com or if a certain feature should even be in a higher price plan - for instance, LDAP integration we may want to only put into Silver, not Bronze.

Tangentially, the direct mapping of Bronze = EES etc... is actually causing some confusion in the market, we are working to change our communications to not talk about it like that externally

closed

Comparison is not for GitLab products, only external products.