Channel Programs Operations

Overview

This page documents the operational information and processes for managing the Channel Program Operations. This page does not include transactional processes, which are available on the Channel Operations Handbook page.

Partner Contracts

Partners register to join the GitLab Partner Program by registering at partners.gitlab.com. You can find more details about the registration process on the Channel Operations Handbook page. As part of that process, partners are able to review and approve the GitLab partner program agreement. For partners that do not agree to all the terms of the agreement, the Legal Request process is available to negotiate contact terms.

The following are the available partner agreements and addenda:

  • Master Partner Agreement (MPA) - This includes the primary terms and conditions for all reseller, services and referral partners.
  • Reseller Addendum - The Reseller addendum covers resale and renewal terms and conditions and must be signed by all partners reselling GitLab products and services.
  • Referral / Services Addendum - This addendum to the MSA defines the terms and conditions for referral and services payment to partners. All partners offering services around GitLab or partners referring, but not resellering GitLab must sign this agreement
  • Managed Services Provider Agreement - This is a special agreement for any partner that will be offering GitLab managed services.
  • Training Partner Addendum - All partners that will be offering GitLab training services utilizing GitLab training materials and train the training programs must sign this addendum.

Copies of the contract templates can be found here.

Partner agreements are limited to a single region (Americas, EMEA, APAC, Public Sector), unless otherwise approved by Channel leadership.

Partner Portal Administration

Members of the Channel team are granted access to the Partner Portal Admin Console. This console enables team members to track partner engagement and view partner data. Partner data is synched between the Partner Portal and Salesforce, so GitLab team members that have access to Salesforce can find all the partner data there.

The Admin console capabilities include:

  1. Engagement metrics - Partner portal engagement metrics, such as logins, asset usage, new accounts and web analytics can be found under the Channel Intel tab.
  2. Salesforce sync - Data is synchronized between the Partner Portal and Salesforce in near real time. As data is updated in one system, it is automatically syned to the other. The Salesforce team, along with Channel Ops and Programs maintain the synchronization. The CRM sync is set up under Admin Settings, CRM.
  3. Workflows - Workflows are set up to take an action based on a new partner being added to the system or updates to a partner account or user record. Workflows are found under the Setting tab. Workflows have been set up to notify team members of a new partner sign ups, automatically provide partners with Portal login credentials, assign journeys, update data fields and other activities. The Channel Programs team maintains the workflows.
  4. Training courses and exams are available for partners in the Portal. The courses are maintained by Field Enablement and Channel Programs. Once the GitLab LXP is rolled out to partners, partners will access the LXP through the portal via single sign-on.
  5. Journeys are set up to assign a partner a set of specific tasks and activities. For example, new partner users are assigned an onboarding Journey. Journeys are set up and maintained by the Channel Programs team.

New Channel Partner Application Process

Reseller, Integrator, MSP, Training, Services and Referral ONLY.

New Partner Sign-Up (Channel Partner Application)

  • Request Portal Access
  • Partner Company Category > Channel Partner Application
  • Partner will fill out Long-Form Contact Information
  • Partner will automatically go into Pending Status
  • Pending Status email will be sent to the registered partner email address
  • Notification Emails will be sent to each Partner Team’s region for each applicant in their region

Pending Status

  • Pending Partners can be found in Impartner under Applicants Tab
  • Pending Partners will stay in Pending Status until Approved or Denied

Approval Process (Partner Vetting Process)

Partner Approved

  • Select Pending partner application
  • Select “APPROVE” of “DENY”
  • Confirm Account: Primary Vertical is Selected
    1. Pending Account > Standard Registration Form > Primary Vertical > (7) Options
    2. If Blank, Select Commercial option
  • Select Approvewithin Step 4: Pending Box
  • Next Window: 3. Select Partner from the Assigned Level drop-down 4. Select Approved from the Assigned Status drop-down 5. Click APPROVEbutton
  • Partner will be Approved and sent an email with their log-in information

Partner Denied

  • Select Pending partner application
  • Select “DENY”

Partner Click-Through Agreement

  • Partner receives an email with their log-in information
  • Once Partner logs in they will be prompted to Read and Agree to GitLab’s Click-Through Partner Agreement
  • Once Agreed, the partner will have access to the partner portal to being the Welcome Onboarding Journey
  • Partners will not be able to fully access the partner portal without Agreeing to the Partner Agreement

Q: Partner says “I’m not able to login” or “my account has been deactivated”

**A:**This could be due to a partner not being registered or an individual thinking they registered before. Or it could be an Alliance partner, those partners currently don’t get portal access. Otherwise, we could’ve deactivated them due to inactivity. Try one of these:

  1. Check to see if the user exists in Impartner.
    • If not, have them register at partners.gitlab.com.
    • If yes, proceed to the next step.
  2. On the Partner Account, check the Partner Status. If this is not “Authorized” or “NDA”, the partner cannot login and should not be activated until they have signed a Partner Agreement. Only set it to Authorized if the partner signed a contract.
    • Is Active? field right now should only be marked “true” if:
      • Partner Type = Channel
      • Partner Status = Authorized (or in rare cases, NDA)

Partner Support Questions

Where do partners and CAMs submit questions?

Slack Channels

  • #channel-sales for general sales engagement questions.
  • #partner-programs-ops for questions about the overall GitLab Partner Program, rules, governance, enablement and operational processes from deal registration through order.
  • #channel-services for questions about the partner services program and partner engagement in services opportunities.
  • #resellers for partners to submit questions.

Email and Chatter Aliases

  • Chatter @Partner Help Desk in Salesforce from Accounts or Opportunities for help with specific internal partner-related requests.
  • partnersupport@gitlab.com for external partner requests and general questions.
  • partners@gitlab.com for messages to the entire channel team.

The Partner Help Desk team has compiled a list of issues and solutions to the most common Partner Portal, application and data questions into an FAQ doc. Please start here to address any issues. This document also includes some of the PHD current state internal processes.

Partner Services Program Management

Help Your Partners Become a GitLab Designated Professional Services Partner (PSP)

Step 1: Introduce your partners to the GitLab Partner Services Program

Step 2: Set an enablement plan with the partner representative that identifies their key employees who sign up for training and become certified to meet the competency requirements for the program.

Step 3: Build a business plan to incorporate GitLab as a strategic element in their service practice using our Service Development Framework

Step 4: Partner Support team awards partners their designation using GitLab Partner Portal.

GitLab Professional Services Partner Designation Award Process

GitLab partners who are compliant with the partner program are eligible to become a GitLab Designated Professional Services Partner (PSP).

The requirements for the GitLab Professional Service Partner badge can be found on the Channel Services Handbook Page.

GitLab Professional Services Partner Designation Award Process

When a partner completes the PSP criteria, the monthly report will trigger the following in the GitLab Partner Portal:

  1. Send the appropriate designation award email to the main Partner contact person listed in the account profile. The award email contains the following elements:
    1. Congratulations
    2. Access to a Badge Graphic Download
    3. Directs partners to our social media sharing kit to help them effectively announce their new certification per our social media kit.
  2. The report will automatically trigger the following change in the GitLab Partner Portal parter profile:
    1. Update the partner portal account information with the new designation and date of award
    2. Display the PSP designation on the partner locator for the account.

GitLab Professional Services Partner Designation Revocation Process

When a partner annual audit identifies a non-compliant PSP, the monthly report will trigger the following in the GitLab Partner Portal:

  1. Send the appropriate designation revocation email to the main Partner contact person listed in the account profile. The award email contains the following elements:

    1. Change of status notification message.
    2. Directs the partner to the handbook site for further information on returning to compliance

  2. The report will automatically trigger the following change in the GitLab Partner Portal parter profile:

    1. Update the partner portal account information to remove the designation and date of award
    2. Remove the PSP designation on the partner locator for the account.

Internal NFR Request Processes

General NFR Request Process

Partner fills out the NFR License Request form from the “Support” tab within the partner portal.

This creates a new line in the associated spreadsheet.

Notification is sent from the spreadsheet to anyone who has notifications set up (see Set Up Google Form Spreadsheet Notifications [insert link to heading]).

Partner Help Desk (PHD) reviews request to verify:

  • If the partner account is Authorized in Impartner
  • If there are any existing NFR licenses - check license.gitlab.com with the partner account name to see if the Partner already has any existing NFR licenses.
    • Select Partners are allowed up to 25 licenses, Open Partners up to 10 licenses
    • If existing licenses, set the expiration date to the same expiration date as existing license (unless this is a renewal of course)
  • If the partner has at least one employee who has completed the Solution Architect Certification or Professional Services Engineer Certification training, lab and exam (with a passing score).

    • Check in Impartner for certifications by going to the Training tab

    • Next to the Certification: Solution Architect Core, click the number in the “Completed” column to display all certification completions and sort by account to see if a certification has been completed.

    • Next to the Certification: GitLab Trusted Professional Services Engineer (PSE) Certification, click the number in the Completed column and sort by account to see if a certification has been completed.

    • If the partner has no certifications yet, but meets the other two eligibility criteria above, currently we can still send the NFR license, but we should encourage the partner to complete the Solution Architect Core. See sample email to Partner contact and CAM, once the license has been sent, below:

      _Subject Line: NFR License Request_

_Hi [Partner License Contact],_

_We just sent you an email with your NFR license, please let us know if you did not receive it._

_To ensure you receive the most value from this license, we encourage you or someone in your organization to complete the available parts of the Solution Architect Core certification in the Partner Portal._

_Please let us know if you need anything else._

_Kind regards,_

PHD works with partner if additional information is needed.

If verified, PHD follows the **Creating and Sending NFR Licenses [insert link to heading]**process (i.e. goes to license.gitlab.com and creates new license according to the request submitted in the form).

When submitted, an email with the license is auto-generated to the Contact Email provided and is auto-logged under the Contact Name in Salesforce.

  • To confirm the license has been sent, find the Contact Name in Salesforce and then view the Activity History on the contact record. The activity Subject will be Email: GitLab Ultimate Trial License Key for… with the email address and a reference number.

PHD informs requestor license has been sent.

Creating and Sending NFR Licenses

  1. Once you’ve confirmed the partner is eligible to receive NFR licenses, login to license.gitlab.com

  2. Click the green button in the upper right corner “New license”

  3. Enter this info at minimum:

    • Name
    • Company
    • Email
    • Users count
    • GitLab Plan = Ultimate (default)
    • Check Trial checkbox
    • Starts at = Today’s date
    • Expires at = 1 year (unless the partner already has existing NFR licenses, then set to the expiration date of the existing license so that all licenses expire the same day and can be reviewed and renewed, if needed, at the same time)
    • Notes = [User count] [GitLab Plan] NFR Licenses for Partner: [Insert Name]

  4. Click Create License button

Access Request to Generate NFR Licenses

In order to send NFR licenses to partners, you first need to have access to dev.gitlab.org. This access then allows you access to license.gitlab.com, where we issue NFR licenses from.

Access Request for dev.gitlab.org

Create a Single Access Request copying the text and updating with your own information using this issue as an example.

  1. Title: First and Last Name, need access to dev.gitlab.org
  2. Type: Issue
  3. Write: (Delete everything above Person Details)
    1. Fill in _Person Details_section with your information, no SSH key needed
    2. Under Account Creation go down to the checkboxes for System name:
      1. _System name:_dev.gitlab.org
      2. _Justification for this access:_I need access to this system so that I can also login and gain access to license.gitlab.com. As a Partner Help Desk Specialist, I will be fulfilling and creating new NFR licenses for Channel Partners for their internal use/demo purposes.
    3. When is access needed? Check the box next to “Within next 72 hours” and add the corresponding label in the Labels section.
  4. _Assignee: Your Manager,_Yourself (so you can track)
  5. Labels: IT::to do, AR-Priority::3 (other labels will be auto-added)
  6. Click Submit Issue button
  7. In the _Comments_section below the body of the issue, type: @gitlab-com/gl-security/corp/helpdesk and then click Comment to post.
  8. You may also want to comment to @your manager to ask them to label AR-Approval Manager Approved and ReadyForProvisioning
  9. Once approved, it should be processed by IT-OPs within the timeframe needed

Once access is granted, you will get an email from dev.gitlab.org “Account was created for you”, make sure you open the email and click the link to set your password.

Logging in to license.gitlab.com

Once your password is set at dev.gitlab.org, go to license.gitlab.com. A login screen will appear, click the green button on the left, “Login with GitLab” and use your email and the password you just created for dev.gitlab.org.

Set Up Google Form Spreadsheet Notifications

Access the NFR License Request Form Google Sheetand set notifications following the instructions below.

You can only set up notifications for yourself. You won’t get notifications when you make changes on your spreadsheet, but you’ll get notifications when others make changes.

Open the form as a spreadsheet in Google Sheets (click the Responses tab on the form and right below that in the top right corner, click the Sheets icon “View responses in Sheets”).

At the top of the spreadsheet, click Tools and then Notification rules.

In the window that appears, select when you want to receive notifications.

Notify you when:

  • Any changes are made: Send notifications when someone makes a change to a spreadsheet.
  • A user submits a form: Send notifications when someone fills out a form.

In the window that appears, select how often you want to receive notifications.

Notify you with:

  • Email - daily digest: Send a daily summary of all changes.
  • Email - right away: Send an email for every change.

Click Save.

Channel Marketing Processes

Complete process for submitting an MDF proposal request for funds and detailed instructions regarding the approval and claim process can be found in the Channel Partner Handbook under MDF.

Select Partners are able to submit MDF requests via the Marketing Page in the Partner Portal. Partners should be reviewing plans with you prior to submitting an MDF request in the Portal to ensure you are aligned with the proposal.

Partner Logos may be accessed in GitLab Partner Portal in the Asset Library under Marketing. Logos are segmented so only authorized Select Partners have access to the Select Logo.

Channel Program Engagement Process

When initiating a project the Channel Team needs to be engaged in each part of the project from ideation to approval. The Channel Engagement process is depicted in Diagram 1 below:

Channel Program Engagement ProcessDiagram 1


Once approved we are ready to begin with engagement with Partner Marketing, Partner Enablement, and the Partner Communication process.

Table 1 outlines the DRIs responsible for each step in the Channel Program Engagement process.

Table 1:

Team DRI
Channel Programs Ed Cepulis
Channel SA Adrian Waters
Channel Operations Colleen Farris
Channel Marketing Coleen Greco
Partner Enablement Blair Fraser
Partner Communications Kim Jaeger

Partner Enablement Tools

The Channel Programs and Enablement team is responsible for the maintence and management of enablement tools used to support the GitLab Partner ecosystem. The three main tools that we use are: Highspot, ImParnter(Partner Portal), and EdCast. Please reference the chart below to determine where an enablement asset should reside.

Partner Enablement Tools

Partner Communications

The Channel Programs and Enablement team is responsible for “To Partner” Communications.

Partners are a huge part of the GitLab go-to-market strategy. Teams managing our product, pricing, or process changes should always consider our Partners as it puts them in the best position to be successful with GitLab customers.

GitLab is contractually obligated to provide Partners with 30 days notification of any pricing, product, or program changes. Product changes to tiering, terms, or EOA must accommodate the 30-day notice before announcing to GitLab customers, so Partners are prepared for changes and to help address customer questions/concerns. The 30 day notification period allows Partners to make required changes to pricelists, company websites, and collateral. As you create GTM and communication plans, please add extra time for the request to the Channel Program team and account for the required 30-day notification.

If you have something to be communicated to our Partners, kindly submit a Channel Partner Announcement request using this template.

For all materials requiring legal review, please refer to the Materials Legal Review Process

The Channel Program team has a standard communication cadence and vehicles to deliver notifications to Partners. Please take into account the communication cadence and delivery dates below, we appreciate and encourage as much notification as possible to allow the team to prepare and schedule requests properly.

News on Demand - Channel Partner communication platform! News on Demand is an add-on product to Impartner, which hosts the Partner Portal.
NOD is used to communicate to Partners via targeted emails and the Partner Flash Newsletter. With NOD, we are able to deliver news that is relevant to the individual user. Partners can access news archives and as a contributor, you can add articles at any time. You do not have to stress about deadlines!

Partner Flash is 100% Targeted - using groups, we can target the audience of each communication or email.

Partner Flash is 100% Personalized- Partners can choose topic preferences and delivery cadence. They can opt to receive the newsletter Daily, Weekly, Bi-Weekly or Monthly. Partners can also access Partner Flash via the “My News” tab in the Partner Portal.

Everyone can Contribute! - Anyone at GitLab can create a story or article for the newsletter! If you would like to be a contributor,click here to fill out the request form. Once approved, navigate to the NOD Home Page to access training and helpful tips.

Partner communication resources and standard delivery dates.

  • Partner Flash Newsletter - delivered to Partner users on the 1st Thursday of the month (occasional exceptions due to holidays or other considerations.) A Partner can elect to receive the newsletter daily, weekly, or bi-weekly. The majority of our Partners receive the newsletter Monthly. If you want to contribute an article, kindly submit it three days before publication.
  • Partner Webcast series - At times, Channel Programs or Channel Leadership might host a Partner webcast to announce a program change or essential updates. Channel Marketing hosts a quarterly Marketing Webcast; other Channel facing teams might elect to host a Webcast for our Partners.
  • Partner Portal Notifications - these alerts can go to all users or a subset; we do not find this a practical stand-alone communication vehicle. Using this notification to augment one of the above resources is more effective.
  • Special Notifications via email - using NOD we can create a one-off notification if there is an urgent need to communicate out-of-cycle announcements or send surveys or Partner SKO/Summit notifications. \

How to get a hold of us: If you have completed the engagement process approvals or have any questions regarding if/how something should be communicated, please reach out to us via the #partner-programs-ops Slack channel.

Partner Flash access - anyone at GitLab can receive Partner Flash or contribute an article.

  • Partners - automatically signed up when approved and authorized via the Partner Portal. If a Partner believes they do not have access please provide the user detail: first and last name, email address, and company name in the**#partner-programs-ops** Slack channel, and we will investigate. Typically we find the Partner has inadvertently opted out of communications. \

  • Internal teams must self-register to receive Partner Flash and Partner Email communications.

    • Use this link to register; it’s pretty straightforward, but check out these instructions if you need assistance.
    • Important:Use your GitLab email address - not a personal address.
    • Select GitLab employee in the drop-down for “Company Type”.
    • Once registered, you will receive an email with instructions on how to edit your communication preferences. \

  • Become a Contributor- If you want to be a contributor,click here and fill out the request form. Once approved, navigate to the NOD Home Pageor click here to access training and helpful tips.

Partner Flash Newsletter

Overview

Partner Flash is a monthly newsletter that recaps important Partner-related information from the month and highlights important upcoming information. The main goal of this communication is to help Partners ramp quickly and grow their GitLab business.

Target Audience

The newsletter is sent to authorized users in our Partner community, the list is gathered and updated from the Partner Portal, new users are added automaticly.

Opportunities/Requirements

The newsletter will…

Uphold our valuesof transparency and allow anyone to contribute**

  • The newsletter is for communication, the Handbook is for documentation. This means that the newsletter will disseminate updates but lean on the Handbook (and other relevant resources) as the main source of documentation, linking back to it wherever possible. Items will also be referenced in the GitLab Partner Portal.

Prioritize repetition, brevity, user-friendliness and added value

  • The newsletter will focus on short lists and bullet points and will link out to more robust resources.
  • Repetition is key to adoption. We will encourage our Channel teams to talk about Partner Flash and will remind Partners in our upcoming Partner Webcast series and on the GitLab Partner portal.
  • We want Partners to value the newsletter. A key to adoption will be successfully positioning it as THE resource to learn what’s new and recap important information. Everything will be tied back to the payoff to the Partner or seller when possible.
  • We must reconcile the fact that this newsletter is yet another increase in communication. We will leverage it to cut down on other communications when possible.

Be fun to look at and read

  • A focus on multimedia is important in order to help the newsletter break the monotony of text Partners sift through each day.
  • We will use images, GIFs, emoji, and video where possible. For example, instead of doing a written win-wire, we will interview the individual and embed that 30-60 second video in the newsletter.

Help the Channel operationalize key messages

  • We will organize information around our 3 main value drivers when possible.
  • We will frequently reiterate Sales and Channel messages through video clips and use-case examples.

Be an opportunity for the Partner Community to “learn themselves”

  • A peripheral goal of the newsletter is to advertise helpful resources to the Partners. We will provide helpful information in hopes that it will encourage them to seek out the source of that information and look for additional information once there.

Highlight all aspects that make a big win possible

  • There are a lot of new Partners and sales reps who are ramping up on GitLab, we want to provide easy to access to information to help them ramp quickly.
  • We will include context around partners and alliances when they play a role in a deal.

Keep the onus on individuals to stay informed

  • GitLab is asynchronous, this communication is in place to help provide quick access to relevant topics, the newsletter is not a substitute for the Handbook or other resources salespeople should be leveraging on the day-to-day.

Be general enough to allow us to remain segment-agnostic

  • The newsletter will include general updates and resources that are applicable to most, if not all, Partners. I
  • Be built out in the open
  • The newsletter content will be compiled using the News On Demand platform. Any team member is welcome to contribute or make requests. See more information in the Process section below.

Uphold our value of “everyone can contribute” we will measure success and gather Partner feedback often.

  • We will measure success using a combination of quantitative and qualitative success metrics. See Measurement section below.
  • Giving feedback or making requests will be easy, and all input will be considered and addressed.
  • The team is committed to upholding the value of the newsletter – information should be relevant, feedback should be actioned on, and leadership should help reiterate by pointing to it as a useful resource for their teams.

Format

Partner Flash - Sections, descriptions, and News Type

Top News - Important announcements (Program Changes) or reminders (Example: Register for Partner Summit or SKO) we should have only ONE item in this category. _News type: Programs, Product, Marketing, Certifications _

New and noteworthy resources - Secondary announcements - services program, new training, significant Partner resources
News Type: Programs, Product Updates

Did You Know? - GitLab highlights or awards (Gartner Report) _Product_updates or use cases
News Type: Corporate & Industry news

Tech Talk - Technical content
News Type: technical, product

Enablement Extras - Provides competitive info for sales or information to assist in the sales process.
News Type: Product, Sales

Marketing & More - Highlights from the Channel Marketing team.
News type: Marketing

What’s new in GitLab? - Reviews highlights of the latest GitLab release
News Type: Product

Events & Announcements - Highlighted events or webcasts for Partners.
News Type: Events

News from our Distributors - any specific Disi notifications or events

Team Member Spotlight - Highlights a Channel Team Member

(NEW!) In Case You Missed It - Highlight an important topic from the Partner Webcast or special announcement with link to any video or recording.
News Type: Product, Program, Technical, Sales

(NEW!) Partner Success! - Partner Services success story to include: Customer problem, Partner solution, Outcome - also to be shared in Field Flash.
News Type: Sales, technical, product

Links we love (as a footer)
GitLab Partner Handbook

Events Calendar (from Impartner)

Process

The newsletter is sent out on the first Thursday of each month.

We build the newsletter using the News On Demand platform, to request to be a contributor please follow the instructions in the Partner Communications.

Quantitative Success Metrics

  • Email open rate - Average open rate of 35% in first 6 months.
  • Click rate - Average click rate of 5% in first 6 months.

Qualitative Success Metrics

  • Increased engagement from our Partner community/leaders and stakeholders in regards to the newsletter – feedback, requests, suggestions, etc.
  • Usefulness of newsletter content as shown by other stakeholders using newsletter content for their own work.
  • Improve the Partner section of the Handbook and the Partner Portal as a result of work on the newsletter.

Channels groups, projects, and labels

Groups Use the GitLab.com group for epics that may include issues within and outside the Channels Team group.

  • https://gitlab.com/groups/gitlab-com/-/boards/1508300?label_name[]=Channel
  • Guidelines for Partner Folders:
    • The partners Group is further divided into regional sub-groups
    • Within each region sub-group Partners will get their own group
    • Partner groups contain a collaboration project and internal project
    • Partner employees should be explicitly invited to collaboration group
    • Internal group should not be visible to non-GitLab employees and may contain licensing details or other sensitive information
    • Additional projects may be created within the partner subgroup to contain code bases for prototypes or PoV
    • Please avoid creating additional subgroups within partner groups

Projects

  • Create issues under the “Channels” project

Labels

  • Team labels
    • Channel- issue initially created, used in templates, the starting point for any label that involves Channels
    • Channel Ops - label for issues that directly impact the Channel Ops & team. DRI will be defined in the intro of the issue
    • Channel Program - label for issues that directly impact the Dir of Channel Programs & team. DRI will be defined in the intro of the issue
    • Channel Services- label for issues that directly impact the Channel Services Manager. DRI will be defined in the intro of the issue
    • Channel Marketing- label for issues that directly impact the Channel Marketing team. DRI will be defined in the intro of the issue
    • Channel Distribution- label for issues that directly impact the Distribution leader. DRI will be defined in the intro of the issue
    • Channel GSI - label for issues that are owned by the Dir of GSI. DRI will be defined in the intro of the issue
    • Internal Channel Enablement- label for issues that are focused on Internal Channel Enablement issues. DRI will be defined in the intro of the issue
    • Channel Handbook Needs- label for issues that are about pending or planned Channel Handbook changes. DRI will be defined in the intro of the issue
    • QBR - Requests from Sales QBRs
  • Priority Weighting (using Eisenhower matrix and weighted tabs in GitLab)
    • WEIGHT 1 ~ Channel Priority:1 - Home runs (high value to GitLab and high likelihood of success that align to Sales & Channel OKRs) and committed to completion within stated milestones. This category will be limited because not everything can be a priority. These are both URGENT & IMPORTANT
    • WEIGHT 2 ~ Channel Priority:2 - Big Bets (high value to GitLab, lower time urgency, longer dependencies or lower likelihood of success) within stated milestones. These are not urgent but IMPORTANT to our success
    • WEIGHT 3 - Channel Priority:3 - Small wins within stated milestones. These are URGENT but not strategically important. Delegate or push out
    • WEIGHT 4 - Channel Priority:4 - Small wins that are important but high value. Should be slotted in where backlog allows
    • WEIGHT 5 - Channel Priority:Backlog - Things in the queue not currently being worked LABEL

DRI To be stated in intro of issue and assigned to that person. There maybe 1 or more assignee but the DRI should be stated intro of issues

Last modified October 29, 2024: Fix broken links (455376ee)
View page source - Edit this page - please contribute. Creative Commons License