Community Relations Department Performance Indicators

1. You are here:
2. Handbook
3. Marketing
4. Community Relations
5. Community Relations Department Performance Indicators

On this page

• Executive Summary
• Key Performance Indicators
  • Meetups per month
  • Wider Community merged MRs per release
  • Developer Evangelism Monthly Impressions
  • GitLab for Education Quarterly Active Seats
• Regular Performance Indicators
  • Wider Community merged MRs per month
  • Unique Wider Community Contributors per Month
  • First time contributors per month
  • GitLab for Education Quarterly New Institutions
  • GitLab for Education Quarterly New Seats
• Other PI Pages
• Legends
  • Health
• How to work with pages like this
  • Pages
    • Helper Functions
  • Data
  • Guidelines

Executive Summary

KPI	Health	Status
Meetups per month	Problem	GitLab is not currently supporting in-person meetups in order to encourage responsible physical distancing within our community. We have increased efforts to organize virtual events.
Wider Community merged MRs per release	Attention	Under target, but showing steady increasing trend, amplified by the collaboration with the Quality Department. Reached baseline for making current contribution process more effective. Ongoing longer term focus on improving the overall contributor journey.
Developer Evangelism Monthly Impressions	Okay	KPI has consistently exceeded threshold in the past 12 months
GitLab for Education Quarterly Active Seats	Attention	All growth prior to FY22Q1 has been organic. Outreach efforts are underway to promote the program. Ongoing longer term focus on outreach (new) and enablement for existing program members (renewals).

Key Performance Indicators

Meetups per month

A GitLab Meetup is defined as a meetup with a presentation given by a GitLab team member or a wider community member about GitLab or a tangential topic. It does not include meetups without GitLab content where GitLab only provides support. This KPI is tracked by counting the number of issues in the GitLab.com data with the Meetups label in the Marketing group.

Each event should have one associated issue with the Meetups label. The issue due date should be set to the event date. The combination of Meetups label and due date will be used by our data dashboard to count the number of meetups each month. This method of tracking can results in errors when meetup issues are created in other groups or when GitLab-related presentations at meetups are not shared with the Community Relations team.

Health: Problem

• GitLab is not currently supporting in-person meetups in order to encourage responsible physical distancing within our community. We have increased efforts to organize virtual events.

Wider Community merged MRs per release

The Wider community contributions per milestone metric reflects the number of merge requests (MRs) merged from the wider GitLab community for each milestone from our GitLab.com data. To count as a contribution the MR must have been merged, have the Community contribution label, have a GitLab milestone set (e.g 11.11, 12.0, etc.) and be against one of the monitored gitlab-org group projects.

Wider community metrics are more reliable after 2015 when the Community contribution label was created, and lastly, there is ongoing work to provide deeper insights into this metric in the Wider Community Sisense dashboard. Further time period representations are provided on the Contributions and contributors over time dashboard

Health: Attention

• Under target, but showing steady increasing trend, amplified by the collaboration with the Quality Department.
• Reached baseline for making current contribution process more effective. Ongoing longer term focus on improving the overall contributor journey.

Chart (Sisense↗)

Lessons Learned (May):

• There is a seasonality to wider community contributions (e.g. lower activities during holiday periods).
• The GitLab Hackathon has a direct impact in increasing a release's contributions.
• Contributions to the www-gitlab-com repository (website and handbook) are generally not represented due to them not having a target milestone.

Developer Evangelism Monthly Impressions

The Developer Evangelism team aims to build thought leadership accross several mediums, primarily through content while exploring various other means. We track impressions of content generated to understand the reach of the generated content, currently we are tracking Twitter impressions, while exploring ways to track other mediums in subsequent iterations.

Health: Okay

• KPI has consistently exceeded threshold in the past 12 months

GitLab for Education Quarterly Active Seats

The GitLab for Education team aims to facilitate and drive adoption of GitLab at educational institutions around the world and build an engaged community of GitLab Evangelists in the next generation of the workforce. We track the number of active seats in the GitLab for Education Program on a quarterly basis as a gauge of program enrollment and rentention. The number of active seats is determied by the number of seats from New Business, Add-ons, and Renewals.

Health: Attention

• All growth prior to FY22Q1 has been organic. Outreach efforts are underway to promote the program.
• Ongoing longer term focus on outreach (new) and enablement for existing program members (renewals).

Regular Performance Indicators

Wider Community merged MRs per month

The Wider community contributions per month metric reflects the number of merge requests (MRs) merged from the wider GitLab community for each month from our GitLab.com data. To count as a contribution the MR must have been merged, have the Community contribution label and be against one of the monitored gitlab-org group projects.

Wider community metrics are more reliable after 2015 when the Community contribution label was created. This PI is also represented by the below Bitergia chart. Further time period representations are provided on the Contributions and contributors over time dashboard

Health: Attention

• Under target, but showing steady increasing trend, amplified by the collaboration with the Quality Department.
• Reached baseline for making current contribution process more effective. Ongoing longer term focus on improving the overall contributor journey.

Lessons Learned (May):

• There is a seasonality to wider community contributions (e.g. lower activities during holiday periods).
• The GitLab Hackathon has a direct impact in increasing a contributions on a given month and the next.

Unique Wider Community Contributors per Month

Distribution of unique authors for all merged Community contribution MRs by month. This is a shared performance indicator with the Quality team.

Wider community metrics are more reliable after 2015 when the Community contribution label was created. This PI is also represented by the below Bitergia chart. Further time period representations are provided on the Contributions and contributors over time dashboard

Target: Above 150 contributors per month

Health: Problem

• This metric is new and we are working with the Quality team to identify target

Chart (Sisense↗)

First time contributors per month

The First time contributors per month metric reflects the number of wider GitLab community members that contribute for the first time to GitLab on a given month. To count as a first time contributor, their MR must have been merged, have the <a href="https://about.gitlab.com/handbook/marketing/community-relations/code-contributor-program/#contribution-labels>1st-time-contributor label</a> and be against one of the monitored gitlab-org group projects.

Wider community metrics are more reliable after 2018 when the 1st-time-contributor label was created. This PI is also represented by the below Bitergia chart. Further time period representations are provided on the Contributions and contributors over time dashboard


Note - if you cannot see this chart, please go to the original Bitergia chart.

Health: Problem

• Unknown at this time, further research is required.

GitLab for Education Quarterly New Institutions

This is a subset of an existing KPI. Please see the definition for the parent KPI.

We track the number of new intitutions joining the GitLab for Education Program on a quarterly basis. The number of new institutions is a gauge for program awareness and expansion.

Health: Attention

• All growth prior to FY22Q1 has been organic. Outreach efforts are underway to promote the program.

GitLab for Education Quarterly New Seats

This is a subset of an existing KPI. Please see the definition for the parent KPI.

We track the number of new seats in GitLab for Education Program on a quarterly basis. The number of new seats is a gauge for GitLab adoption.

Health: Attention

• All growth prior to FY22Q1 has been organic. Outreach efforts are underway to promote the program.

Other PI Pages

• Performance Indicator Maturity Table
• Engineering Function Performance Indicators
  • Customer Support Department Performance Indicators
  • Development Department Performance Indicators
  • Infrastructure Department Performance Indicators
  • Quality Department Performance Indicators
  • Security Department Performance Indicators
  • UX Department Performance Indicators
  • Incubation Engineering Department Performance Indicators
• Product Performance Indicators
  • Dev Section Performance Indicators
  • Ops Section Performance Indicators
  • Sec Section Performance Indicators
  • Enablement Section Performance Indicators
  • Stage and Group Performance Indicators
• Corporate Finance Performance Indicators
• Talent Acquisition Performance Indicators
• People Success Indicators
• KPI Index

Legends

Health

Value	Level	Meaning
3	Okay	The KPI is at an acceptable level compared to the threshold
2	Attention	This is a blip, or we’re going to watch it, or we just need to enact a proven intervention
1	Problem	We'll prioritize our efforts here
-1	Confidential	Metric & metric health are confidential
0	Unknown	Unknown

How to work with pages like this

Pages

Pages, such as the Engineering Function Performance Indicators page are rendered by an ERB template that contains HTML code.

• Any changes to the Performance Indicator (PI) ERB template will cascade to all links under the Other PI Pages section
• To add, delete, or update (K)PI information (including title, description, etc), make changes to the corresponding Performance Indicators data file. See more details in the Data section below.
• To update the way each individual (K)PI displays:
  • make changes to the Performance Indicators List ERB file for how the (K)PI is displayed on the KPI Index page
  • make changes to the Performance Indicators ERB file for any other properties and its format
• When adding a new PI page,
  • create the new PI page in the business division's handbook section (like the Engineering Division page)
  • include the relative link to the PI page in the Performance Indicators List ERB file
  • add all the (K)PI information into the corresponding Performance Indicators data file

Helper Functions

These ERB templates calls custom helper functions that extract and transform data from the Performance Indicators data file.

• The kpi_list_by_org(org) helper function takes a required string argument named org (deparment or division level) that returns all the KPIs (pi.is_key == true) for a specific organization grouping (pi.org == org) from the Performance Indicators data file.
• The pi_maturity_level(performance_indicator) helper function automatically assigns a maturity level based on the availability of certain data properties for a particular PI.
• The pi_maturity_reasons(performance_indicator) helper function returns a reason for a PI maturity based on other data properties.
• The performance_indicators(org) takes a required string argument named org (deparment or division level) that returns two lists - a list of all KPIs and a list of all PIs for a specific organization grouping (department/division).
• The signed_periscope_url(data) takes in the sisense_data property information from Performance Indicators data files and returns a signed chart URL for embedding a Sisense chart into the handbook.

Data

The heart of pages like this are Performance Indicators data files which are YAML files. Each - denotes a dictionary of values for a new (K)PI. The current elements (or data properties) are:

Property	Type	Description
name	Required	String value of the name of the (K)PI. For Product PIs, product hierarchy should be separate from name by " - " (Ex. {Stage Name}:{Group Name} - {PI Type} - {PI Name}
base_path	Required	Relative path to the performance indicator page that this (K)PI should live on
definition	Required	refer to Parts of a KPI
parent	Optional	should be used when a (K)PI is a subset of another PI. For example, we might care about Hiring vs Plan at the company level. The child would be the division and department levels, which would have the parent flag.
target	Required	The target or cap for the (K)PI. Please use Unknown until we reach maturity level 2 if this is not yet defined. For GMAU, the target should be quarterly.
org	Required	the organizational grouping (Ex: Engineering Function or Development Department). For Product Sections, ensure you have the word section (Ex : Dev Section)
section	Optional	the product section (Ex: dev) as defined in sections.yml
stage	Optional	the product stage (Ex: release) as defined in stages.yml
group	Optional	the product group (Ex: progressive_delivery) as defined in stages.yml
category	Optional	the product group (Ex: feature_flags) as defined in categories.yml
is_key	Required	boolean value (true/false) that indicates if it is a (key) performance indicator
health	Required	indicates the (K)PI health and reasons as nested attributes. This should be updated monthly before Key Reviews by the DRI.
health.level	Optional	indicates a value between 0 and 3 (inclusive) to represent the health of the (K)PI. This should be updated monthly before Key Reviews by the DRI.
health.reasons	Optional	indicates the reasons behind the health level. This should be updated monthly before Key Reviews by the DRI. Should be an array (indented lines starting with dashes) even if you only have one reason.
urls	Optional	list of urls associated with the (K)PI. Should be an array (indented lines starting with dashes) even if you only have one url
funnel	Optional	indicates there is a handbook link for a description of the funnel for this PI. Should be a URL
sisense_data	Optional	allows a Sisense dashboard to be embeded as part of the (K)PI using chart, dashboard, and embed as neseted attributes.
sisense_data.chart	Optional	indicates the numeric Sisense chart/widget ID. For example: 9090628
sisense_data.dashboard	Optional	indicates the numeric Sisense dashboard ID. For example: 634200
sisense_data.shared_dashboard	Optional	indicates the numeric Sisense shared_dashboard ID. For example: 185b8e19-a99e-4718-9aba-96cc5d3ea88b
sisense_data.embed	Optional	indicates the Sisense embed version. For example: v2
sisense_data_secondary	Optional	allows a second Sisense dashboard to be embeded. Same as sisense data
sisense_data_secondary.chart	Optional	Same as sisense_data.chart
sisense_data_secondary.dashboard	Optional	Same as sisense_data.dashboard
sisense_data_secondary.shared_dashboard	Optional	Same as sisense_data.shared_dashboard
sisense_data_secondary.embed	Optional	Same as sisense_data.embed
public	Optional	boolean flag that can be set to false where a (K)PI does not meet the public guidelines.
pi_type	Optional	indicates the Product PI type (Ex: AMAU, GMAU, SMAU, Group PPI)
product_analytics_type	Optional	indicates if the metric is available on SaaS, SM (self-managed), or Both.
is_primary	Optional	boolean flag that indicates if this is the Primary PI for the Product Group.
implementation	Optional	indicates the implementation status and reasons as nested attributes. This should be updated monthly before Key Reviews by the DRI.
implementation.status	Optional	indicates the Implementation Status status. This should be updated monthly before Key Reviews by the DRI.
implementation.reasons	Optional	indicates the reasons behind the implementation status. This should be updated monthly before Key Reviews by the DRI. Should be an array (indented lines starting with dashes) even if you only have one reason.
lessons	Optional	indicates lessons learned from a K(PI) as a nested attribute. This should be updated monthly before Key Reviews by the DRI.
lessons.learned	Optional	learned is an attribute that can be nested under lessonsand indicates lessons learned from a K(PI). This should be updated monthly before Key Reviews by the DRI. Should be an array (indented lines starting with dashes) even if you only have one lesson learned
monthly_focus	Optional	indicates monthly focus goals from a K(PI) as a nested attribute. This should be updated monthly before Key Reviews by the DRI.
monthly_focus.goals	Optional	indicates monthly focus goals from a K(PI). This should be updated monthly before Key Reviews by the DRI. Should be an array (indented lines starting with dashes) even if you only have one goal
metric_name	Optional	indicates the name of the metric in Self-Managed implemenation. The SaaS representation of the Self-Managed implementation should use the same name.

Guidelines

Please reference the Engineering Metrics Page for guidelines on chart visualization formatting.