Skip to content

Design features with self-managed in mind over SaaS-first

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.

TL;DR - Engineers, Product Managers, and Designers were missing out on how to design features appropriately for self-managed and SaaS solutions. This MR aims to add more guidance on how to support releasing to SaaS while planning for the demands of Self-managed customers.

--

The SaaS-first principle can lead to some ambiguous interpretations where features are designed as SaaS only while they could be very valuable for self-managed. In essence this principle can undermine the feature parity between SaaS and self-managed principle.

If SaaS-first is more related to deploying features on SaaS-first, in order to give features to users faster and collect feedback, then let's make it clear and remove any ambiguity.

The principle about Feature parity between SaaS and self-managed can also be left to interpretations because we don't specify what design approach we recommend. We specify that eventually there should be feature parity. The reality is that some features today can be designed to solve SaaS-specific problems and never (fully) enabled on self-managed.

A random example: CI compute minutes was designed to be a SaaS feature but could be very valuable for self-managed and Dedicated customers. This feature partially works on self-managed.

  • Cost factors are configurable on SaaS but not on self-managed.
  • Requesting extra compute minutes could be a feature also enabled on self-managed. On SaaS that would be implemented as a self-service purchase, while on self-managed requests could be approved by admins.

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
    • Division: If the update affects your division, share the MR in your division 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

Commits

  • Design features with self-managed in mind

In order to achieve maximum feature parity between SaaS and self-managed, we cannot design features as SaaS-first. The SaaS-first principle has led to some ambiguous interpretations where features were designed as SaaS only while they could have been useful for self-managed.

Also, being Gitlab.com and Dedicated also a kind of self-managed installations, optimizing design and deployments for self-managed means that all other installations will get the benefits.


Edited by Jackie Porter

Merge request reports