Engineering Productivity team

1. You are here:
2. Engineering
3. Quality Department
4. Engineering Productivity team

Maintained by:

Kyle Wiebers

@kwiebers

On this page

• Common Links
  • Office hours
• Vision
  • Mission
  • Workstream objectives
• Areas of Responsibility
• Team Members
• Team meetings
  • Showcase
• Work prioritization
• Projects
• Engineering productivity team metrics
• Team gearing ratio
• Communication guidelines
  • Pipeline changes
    • Critical pipeline changes
    • Non-critical pipeline changes
  • Automated triage policies
• Experiments

Child Pages

GDK

Flaky tests

Common Links

Office hours

Engineering productivity has monthly office hours on the 3rd Wednesday of the month at the 13:30 UTC (6:30 PST) on odd months (e.g January, March, etc) and 3:00 UTC (20:00 PST) on even months (e.g February, April, etc) open for anyone to add topics or questions to the agenda. Office hours can be found in the GitLab Team Meetings calendar

Vision

The Engineering Productivity team increases productivity of GitLab team members and contributors by shortening feedback loops and improving workflow efficiency for GitLab projects. The team uses a quantified approach to identify improvements and measure results of changes.

Mission

Reduce pipeline cost, reduce pipeline duration, and increase pipeline stability for GitLab projects focusing on projects with the largest reach, leveraging GitLab features where possible.

Improve engineering workflow automation to decrease Open MR Review Time (OMRT) and Open MR Age (OMA), and decrease open ~"type::bug" age.

Enable frequent and positive experience of Community Contributions from the Wider GitLab Community.

Workstream objectives

The Engineering Productivity team focuses on the following workstreams and the associated Epics with workstream specific vision and objectives.

Areas of Responsibility

• See it and find it: Build automated measurements and dashboards to gain insights into the productivity of the Engineering organization to identify opportunities for improvement.
  • Implement new measurements to provide visibility into improvement opportunities.
  • Collaborate with other Engineering teams to provide visualizations for measurement objectives.
  • Improve existing performance indicators.
• Do it for internal team: Increase contributor and developer productivity by making measurement-driven improvements to the development tools / workflow / processes, then monitor the results, and iterate.
  • Identify and implement quantifiable improvement opportunities with proposals and hypothesis for metric improvements.
  • Automated merge request quality checks and code quality checks.
  • GitLab project pipeline improvements to improve efficiency, quality or duration.
• Dogfood use: Dogfood GitLab product features to improve developer workflow and provide feedback to product teams.
  • Use new features from related product groups (Analytics, Monitor, Testing).
  • Improve usage of Review Apps for GitLab development and testing.
• Engineering support: Participate in activities related to Engineering MR Rate and Quality KPIs.
  • #master-broken pipeline monitoring.
  • KPI corrective actions such as Review Apps stabilization.
  • Merge Request Coach for ~"Community contribution" merge requests.
• Engineering workflow: Develop automated processes for improving label classification hygiene in support of product and Engineering workflows.
  • Automated issues and merge requests triage.
  • Improvements to the labelling classification and automation used to support Engineering measurements.
  • See the GitLab Triage, and GitLab triage operations projects for examples.
• Do it for wider community: Increase efficiency for wider GitLab Community contributions.
• Dogfood build: Enhance and add new features to the GitLab product to improve engineer productivity.

Team Members

Team meetings

Engineering Productivity has a weekly team meeting to give kudos, review announcements, discuss agenda items, and demo things to help with knowledge sharing.

Showcase

Team members have the opportunity to present (5-7 minute) demos at the start of the weekly team meeting. The demo topic will be voted on in a Polly at #g_engineering-productivity. Each demo should focus on the What, Why, How and be led by a team member who is sharing their screen explaining the topic.

1. The Engineering Productivity Engineering Manager will maintain a list of topics and demo durations
2. The Engineering Productivity Engineering Manager will open a Polly in Slack for voting on Wednesday which closes on Friday
3. Each channel participant will have one vote to pick a topic for the next team meeting
4. The demo DRI needs to comment in the Polly thread if they are unable to participate

Work prioritization

The Engineering Productivity team uses modified prioritization and planning guidelines for targeting work within a Milestone.

Projects

1. GitLab CI Pipeline configuration optimization and stability.
2. GitLab provisioning.
3. GitLab triage operations for issues, merge requests, community contributions.
4. GitLab Triage engine, used by GitLab triage operations.
5. GitLab Insights (deprecated) and Development department metrics for measurements of Quality and Productivity.
6. GitLab Dangerfiles for shared Danger rules and plugins.
7. GitLab Styles for shared RuboCop cops.
8. GitLab Development Kit (GDK) continued development.

Engineering productivity team metrics

The Engineering Productivity team creates metrics in the following sources to aid in operational reporting.

• Sisense Quality Engineering KPIs
• Sisense Engineering Productivity Sandbox
• Sisense Engineering Productivity Pipeline
• Sisense Engineering Productivity Jobs Durations
• Sisense Engineering Productivity Package And QA Durations
• Sisense GitLab Issue Triage Dashboard
• GitLab-Org Native Insights
• Review Apps monitoring dashboard
  • Failed deployment Tiller logs
• Triage Reactive monitoring dashboard
• Deprecated Quality Dashboard

Team gearing ratio

Exception Ratio: 2 Staff+ Engineering Team

Justification: Engineering Productivity has a wide focus to enable efficiency for GitLab code workflows. The team is implementing productivity improvements and globally optimizing for all workflows (GitLab, JiHu and Contributors). Staff+ team members focus on digging deep into feedback loop bottlenecks (Solver) and ensuring that the approach and implementation is scalable (Tech Lead) by working with counterparts in Development and Infrastructure departments.

Future Growth or Anticipated Change: It is expected that Engineering Productivity will maintain the current ratio during FY22 and re-evaluate in FY23.

Communication guidelines

The Engineering Productivity team will make changes which can create notification spikes or new behavior for GitLab contributors. The team will follow these guidelines in the spirit of GitLab's Internal Communication Guidelines.

Pipeline changes

Critical pipeline changes

Pipeline changes that have the potential to have an impact on the GitLab.com infrastructure should follow the Change Management process.

Pipeline changes that meet the following criteria must follow the Criticality 3 process:

• update of the CI_PRE_CLONE_SCRIPT CI variable
• update to the cache-repo job job

These kind of changes led to production issues in the past.

Non-critical pipeline changes

The team will communicate significant pipeline changes to #development in Slack and the Engineering Week in Review.

Pipeline changes that meet the following criteria will be communicated:

• addition, removal, renaming, parallelization of jobs
• changes to the conditions to run jobs
• changes to pipeline DAG structure

Other pipeline changes will be communicated based on the team's discretion.

Automated triage policies

Be sure to give a heads-up to #development,#eng-managers,#product, #ux Slack channels and the Engineering week in review when an automation is expected to triage more than 50 notifications or change policies that a large stakeholder group use (e.g. team-triage report).

Experiments

This is a list of Engineering Productivity experiments where we identify an opportunity, form a hypothesis and experiment to test the hypothesis.