Package scaling success implications

Why is this change being made?

We've had some recent developments in the Package group:

• We grew the package registry adoption by 541% in FY21
• We've had a few production incidents in the past few months
• We have approval from the exec team to grow the team by 2 backend engineers in May 2021.
• The engineering manager departed the team
• We have an acting engineering manager until we hire a new engineering manager
• We transitioned to a new technical writer

We've been promising to customers and prospects that we will work on virtual registries. Support for virtual registries will help large enterprises move away from Artifactory and is thus desired. But given our current team size and the footprint of the product, breaking ground on virtual registries doesn't make sense.

Why? Because we are seeing such interest and adoption in our current set of features, we should work to improve the reliability and usability of these features to help drive active growth rather than new, vision items. If we lose our early adopters, they may never come back. For customers that are waiting to transition to GitLab, a delay will be frustrating but at least we have a chance to win them back when we add those much-needed features.

So, I'm proposing that while we have reduced headcount we focus on improving our GitLab-hosted registries prior to moving on to external ones. What does that mean?

• Finish adding support for RubyGems
• Understand and expand our test coverage to reduce the number of production incidents and MTTR
• Help migrate to the new container registry and expand the API to power the rollout of cleanup policies and UI performance and improved designs.
• Ensure all package metadata is in the UI
• Hire and on-board new team members so that we can expand the breadth of the product while still supporting rapid growth and adoption

Author Checklist

• Provided a concise title for the MR
• Added a description to this MR explaining the reasons for the proposed change, per say-why-not-just-what
• Assign this change to the correct 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 in 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.
  • If the changes relate to any part of the project other than updates to content and/or data files please make sure to ping @gl-static-site-editor in a comment for a review and merge. For example changes to .gitlab-ci.yml, JavaScript/CSS/Ruby code or the layout files. (this requirement has been removed pending identification of a new DRI for the handbook)