Package:Package Registry Group

📦 The Team

The Package Registry is part of the GitLab Package stage, which integrates with GitLab’s CI/CD product.

Who We Are

Team Members

The following people are permanent members of the Package Registry Group:

Name	Role
Crystal Poole	Senior Engineering Manager, Package
David Fernandez	Staff Backend Engineer, Package:Package Registry
Dzmitry Meshcharakou	Senior Backend Engineer, Package:Package Registry
Moaz Khalifa	Backend Engineer, Package:Package Registry
Rad Batnag	Senior Backend Engineer, Package:Package Registry

Stable Counterparts

The following members of other functional teams are our stable counterparts:

Name	Role
Greg Myers	Security Engineer, Application Security, Package (Package Registry, Container Registry), US Public Sector Services, Gitaly Cluster, Analytics (Analytics Instrumentation, Product Analytics), AI Working Group
Jackie Porter	Director of Product Management, Verify & Package
Tim Rizzi	Principal Product Manager, Package

How We Work

Directly Responsible Individual (DRI)

A DRI is assigned to every substantial project or initiative the team works on. A project is considered substantial when the work involved is expected to span more than two milestones. When projects take that long to deliver, tasks such as the planning and breakdown of deliverables and regular async updates become increasingly important for the project’s success. Therefore, it makes sense to enforce the assignment of a DRI, who will be personally accountable for those tasks.

We strongly encourage everyone on the team to step forward and sign up as DRI for new projects. Ideally, all team members should experience this role over time. This promotes shared ownership, accountability and development opportunities for all team members.

In case of critical, unusually long, or highly complex projects, a specific DRI with the most experience on the subject may be assigned by the Engineering Manager. In these situations, other team members may volunteer or be assigned to shadow the assigned DRI and act as backup. This provides not only a learning opportunity for newer team members but also redundancy.

Apart from what is described in the DRI handbook page, DRIs leading projects on the team must perform the following tasks:

• Make sure the epic that serves as single source of truth for the project is kept up to date, and so are the individual sub epics and issues under;
• Make sure to consistently provide a weekly async update on the related epic. Low-level updates on sub-epics are optional. High-level updates on the root epic are required.
• Ensure there is at least one issue ready to be scheduled on the next milestone;
• Engage with the Product Manager to have the issue(s) ready for development scheduled in the next milestone;
• Keep the Engineering Manager and Product Manager aware of any unexpected changes to the plan;
• Consult and collaborate with other DRIs when inter project dependencies or blockers are identified;
• Consult with other engineers when the project’s technical scope changes.

The DRI for a given project can be identified by looking at the corresponding epic’s description, where a section as follows should be added:

1
2
3
4
5
6
7

## Owners

* Team: [Package Registry](/handbook/engineering/development/ops/package/package-registry/)
* Most appropriate slack channel to reach out to: `#g_package-registry`
* Best individual to reach out to: <!-- GitLab handle of the DRI, or "TBD" if none has been assigned yet -->
* PM: @trizzi
* EM: @crystalpoole

Additionally, we maintain a list of active projects and the assigned DRI on this page, in What Are We Working On.

DRI for package manager formats

The Package Registry supports several different package manager formats. Although the functionality between formats is similar, there is enough nuance in the implementation and maintanence of each format that we have DRI’s for each format.

How we handle breaking changes

Announce deprecations, breaking changes, and removals at least 3 milestone before (according to https://docs.gitlab.com/ee/development/deprecation_guidelines/#when-can-a-feature-be-removedchanged).

• Before the major version milestone: implement the breaking change with a feature flag. A feature flag will be used every time unless there is a very good argument not to.
• In the major version milestone:
  • Rollout the feature flag.
  • If no issues are detected, the change is considered stable and we can open the feature flag cleanup MR.

By implementing the change before the major milestone we have less MRs to produce on the major version milestone. In addition, it allows more flexiblity. For example, if the rollout goes wrong. We have then two paths:

• We can fix it before the end of the major version milestone and do the rollout again or
• We can disable the feature flag and wait for the next major version milestone to re-do the rollout.

📈 Measuring results

OKRs

We use quarterly Objectives and Key Results as a tool to help us plan and measure how to achieve Key Performance Indicators (KPIs).

Here is the standard, company-wide process for OKRs

Performance indicators

We measure the value we contribute by using performance indicator metrics. The primary metric used for the Package Registry group is the number of monthly active users or GMAU.

What Are We Working On

Here is a list of active projects and initiatives that we are currently working on, along with the corresponding DRI:

Documentation

Package Registry documentation is available here.

View page source - Edit this page - please contribute.