Collaboration on shared feature and experience areas

Cross-stage feature collaboration

Each stage is responsible for building functionality that furthers their vision and direction. Even if some components of that functionality happen to cross into spaces typically owned by other stages, they should still build it (if it’s important to them).

If the feature isn’t necessary or urgently needed to move forward (for example, it won’t block another feature’s development), then you can always consider putting it on the backlog of the stage that owns that feature.

Here are some guidelines for thinking about “Which stage should do this work?”:

1. If a stage wants to develop new functionality that is core to their value, even if it happens to live inside a feature owned by another stage, they should still build it.
2. Alternately, if the functionality lives inside another stage’s feature, but is also very-much a “nice-to-have”, they should consider putting it in an issue and labeling it appropriately. This way, the stage that owns that feature can prioritize it at a later date when it makes sense for them to do so.
3. External requests for integration with 3rd-party systems should be routed to the group closest to the integrations value proposition or affected area.

Ownership of existing integrations

The tables below show the ownership of integrations living in the GitLab codebase.

Security Related Integrations

CI/CD Integrations

External Issue Trackers

Source Code Integrations

Project Management Integrations

Authentication Integrations

Container and Package Integrations

Search Integrations

Incubation Integrations

Notification Integrations

Other Integrations

DRI Group Responsibilities

Product groups designated as DRIs for integrations are responsible for:

• Deciding if new community-contributed integrations should be added to GitLab codebase based on their domain strategy
• Determining if existing integrations should remain in GitLab codebase according to domain strategy
• Following proper process for deprecating and removing integrations when needed
• Maintaining integration documentation
• Re-assigning and triaging integration-related issues to determine prioritization
• Remediating bugs and security vulnerabilities within target SLOs
• Addressing infradev issues and responding to urgent requests
• Responding to Requests for Help and iterating on the integration

Product groups may also designate certain integrations as Community-supported for improvements and additional features at their discretion.

This model allows teams to be flexible and calibrate their priorities accordingly, and no team should ever be “blocked.” Exceptions may be items where a change requires anything that a software engineer would not be allowed to do, such as a production change, in which case the infrastructure team would be the blocker.

While any team can contribute features to any stage, it is recommended to loop in the most relevant PM from that Group to provide strategic support to help the contributing team align to the Group’s broader plan and vision.

Below is a guide to help other product groups understand how to work on these areas and quickly locate the best parties who may assist on the subject matter.

This section is modeled after the engineering handbook version of ownership of shared services and components.

Existing Cross-Stage Capabilities

• Merge Requests - also see collaboration process
• Define your CI/CD pipelines directly in your repository
• Releases associated to milestones
• Generate a Release from .gitlab-ci.yml
• Create a GitLab or Jira issue from a vulnerability
• Create a merge request from an issue
• Measure DevOps success via the DORA metrics
• Create Incidents as an Issue Type
• Connect your clusters via the CI/CD Tunnel
• Relate issues and Feature Flags
• Run multiple pipelines and project dependencies with multi-project pipelines
• Enable concurrency control during deployments with Resource Groups
• Associate job artifacts, or a generic package to a Release

Planned Cross-Stage Improvements

• Software Supply Chain Security

View page source - Edit this page - please contribute.