Add GitLab.com strategy

Why is this change being made?

Provide a detailed answer to the question on why this change is being proposed, in accordance with our value of Transparency.

Please add the details saying why, not just what in this section. Example: We have discussed the topic in Slack - (copy of Slack conversation). The current process is not efficient, this MR makes the description of X more clear, and helps move Y forward.

This MR adds a direction page for gitlab.com, where we will host the gitlab.com strategy that cascades down to and aligns with other groups direction in SaaS Platforms

Preview link - https://dotcom-strategy.about.gitlab-review.app/direction/saas-platforms/dotcom/

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
  • The when to get approval handbook section explains the workflow in more detail
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

Commits

• Init Draft

---

source/direction/saas-platforms/dotcom/index.html.md

@@ -19,7 +19,12 @@ Our SaaS offerings make up an [increasing percentage of revenue](https://ir.gitl
 ### High Operational Load
-Gitlab.com teams are responsible for the continued operations of the systems that are essential to deliver our mutli tenant platform. Onboarding, operating, and maintaining these systems have a high cognitive and operational load. As a consequence, project work that could evolve our deployment capabilities and unlock new business opportunities can be deprioritized over “keep the lights on work” which prevents/mitigates user impact.
+Gitlab.com teams are responsible for the continued operations of the systems that are essential to deliver our multi tenant platform. 
+Onboarding, operating, and maintaining these systems have a high cognitive and operational load. 
+As a consequence, project work that could evolve our deployment capabilities and unlock new business opportunities can be deprioritised over “keep the lights on work” which prevents/mitigates user impact.
+
+Additionally, GitLab.com is operating at the largest edge of what GitLab handles as a product.
+This can reveal subtle, but significant issues that most customers operating GitLab will never experience, but create a large demand on the teams that support GitLab.com.
 ### Ownership of a Shared Platform
@@ -27,7 +32,7 @@ GitLab teams have a large amount of autonomy and are empowered to work on things
 ### Staffing & Perception
-Infrastrucutre teams are typically staffed very lean as a consequence of being understood as a "cost centre" for the business. Preventative cost avoidance is hard to account for and model and often leads to underinvestment in groups that prevent and manage negative business outcomes. We are already starting to change the perception of SaaS Platforms into a revenue generator or "profit centre" with GitLab Dedicated and Runway and there is a significant opportunity to build more compelling faetures which further drive our transformation into a principal revenue generator for GitLab.
+Infrastructure teams are typically staffed very lean as a consequence of being understood as a "cost centre" for the business. Preventative cost avoidance is hard to account for and model and often leads to underinvestment in groups that prevent and manage negative business outcomes. We are already starting to change the perception of SaaS Platforms into a revenue generator or "profit centre" with GitLab Dedicated and Runway and there is a significant opportunity to build more compelling faetures which further drive our transformation into a principal revenue generator for GitLab.
 ## 3-5 Year Strategy
@@ -39,11 +44,11 @@ GitLab.com is our multi-tenant SaaS platform, where we are able to offer the mos
 GitLab currently has an availability target (SLO) of two 9s (99.80%). However, based on [3 years of historical data](https://handbook.gitlab.com/handbook/engineering/monitoring/#historical-service-level-availability) from August 2021 to August 2024, we achieve an average of three 9s (99.94%) in our availability SLI. Three 9s is the high end of availability targets set for complex SaaS applications across the industry including applications like GitHub. In order to win against GitHub in the long term, we need to increase our availability to be best in class across the industry. 
-Best in class means putting in place an SLO of four 9s as a clear differentiator of our This will require a shared effort between many groups within SaaS platforms and some foundational investments and rearchitecture of existing systems.
+Best in class means putting in place an SLO of four 9s as a clear differentiator. This will require a shared effort between many groups within SaaS platforms and some foundational investments and re-architecture of existing systems.
 ### Improve the Quality of our Product Development Practice through Stewardship
-As stewards of GitLab.com, Delivery, Scalability & Production Engineering have a responsibility to ensure that GitLab.com remains operational and reliable every minute of every day. Shifting more things left in the SDLC is commonly accepted practice in software development as the most efficient way to deliver higher quality production systems.
+As stewards of GitLab.com, Delivery, Scalability & Production Engineering have a responsibility to ensure that GitLab.com remains operational and reliable every minute of every day. Shifting more things left in the software development lifecycle (SDLC) is commonly accepted practice in software development as the most efficient way to deliver higher quality production systems.
 Globally improving our product and software development practice will result in a higher quality product, with fewer errors and incidents. That will enable teams to be more efficient with their time and bias work toward preventative measures rather than reactive measures post incident. In order to do this, we essentially have 2 levers: