Category Maturity Updates

Why is this change being made?

In the PLT offsite for Q3, we discussed simplifying the maturity model to improve the perception of our product offering from external users and customers. To do this we are going to remove Lovable and add a Competitive maturity.

This MR:

1. Updates the Maturity information to include the new descriptions and criteria
2. Moves Marketing Categories that were "lovable" categories to "Complete"
   • source_code_management:
   • code_review_workflow:
   • omnibus_package:
3. Moves Marketing categories that were "Complete" to "Competitive"
   • web_ide:
   • pages:
   • continuous_integration:
   • review_apps
   • continuous_delivery:
   • groups_and_projects:
   • cloud_native_installation:
   • disaster_recovery:
4. Moves non-marketing that were "Lovable" categories to "Viable"
   • runner
5. Moves Non-marketing categories that were "Complete" to "Viable"
   • fleet_visibility:
   • build:
   • geo_replication:

Next Steps

Once we merge this MR, we will need to instruct PMs and Product Designers on what to do to progress former "Lovable" and "Complete" categories. The proposal that @asmolinski2 @hbenson and @vkarnes worked through is the following:

1. How do we want to handle experiences that have already been rated as Loveable and Complete in the past?
   • For all categories that are currently Complete:
     1. They will be downgraded to “Viable”
     2. In Q1-Q2 product managers and product designers will complete the competitive add-on evaluation with at least 1 competitor for categories to be classified as “Competitive” 
        1. GitLab needs to score: Equal or Best in class
   • For all categories that are currently “Lovable”:
     1. They will be downgraded to “Viable”
     2. In Q1-Q2 product managers and product designers will complete the competitive add-on evaluation with at least 1 competitor for categories to be classified as “Competitive” 
        1. GitLab needs to score: Best in class
     3. If a Category Maturity Scorecard has been completed in the past two years, and a score of 3.95 or higher has been attained then a maturity of “Complete” can be assigned.
        1. If a Category Maturity Scorecard has not been completed or it has been longer than 2 years if desired, the product manager and product designer can complete a CMS, and if a score of 3.95 or higher is attained a maturity of “Complete” can be assigned. 
2. On the Design requirements side: What happens with categories that were rated using the previous rating model (defined as before 2023-12-01)?

• In some cases, teams will have to revisit their categories to determine how they score using the new rating model.  If your category was scored before 2023-12-01, the following applies:
  • If it previously scored as ‘Loveable’
    • (note this is now named ‘Complete’)
    • No action needed for meeting GitLab design standards; assumption is that it’s being met at this level
    • No action needed for Usability status; assumption is that it’s being met at this level.
  • If it previously scored as ‘Complete’
    • (note this is now named ‘Competitive’)
    • No action needed for meeting GitLab design standards; assumption is that it’s being met at this level
    • No action needed for Usability status; assumption is that it’s being met at this level.
  • If it previously scored as ‘Viable’
    • The experience needs to be evaluated to determine if 100% of the GitLab design standards are being met.
      • If the experience doesn’t meet this criterion, a time-boxed plan is to be put in place to give teams an opportunity to address it before needing to downgrade. If the team determines they're unable to address it within that time frame, then they can opt to downgrade immediately.
    • No action needed for Usability status; assumption is that it’s being met at this level.
  • If it previously scored as ‘Minimal’
    • The experience needs to be evaluated to determine if 80% of the GitLab design standards are being met.
      • If the experience doesn’t meet this criterion, a time-boxed plan is to be put in place to give teams an opportunity to address it before needing to downgrade. If the team determines they're unable to address it within that time frame, then they can opt to downgrade immediately.
    • No action needed for Usability status; assumption is that it’s being met at this level.

ASK: Please review this MR proposal above and the changes for categories. Add any concerns or suggestions.

---