Program Resources and Workflows

This page contains the tools and workflows used to drive awareness, engagement, retention and advocacy of our programs.

Communication channels

Slack

The team uses the following Slack channels:

Channel Access Description
strategy-programs Public For open discussion of GitLab for Open Source and GitLab for Education programs
strategy-programs-confidential Private For discussion of confidential topics related or relevant to the Strategy Programs team
cocreate-initiative Public For open discussion of the Co-Create program
cocreate-initiative-confidential Private For discussion of confidential topics related to the Co-Create program
contributor-success Public For open discussion of topics related to the Contributor Success team
contributor-success-and-strategy-programs-confidential Private For discussion of confidential topics related to the Contributor Success and Strategy Programs teams
strategy-programs-sustainability Private For discussion of confidential topics related to the programs managed by Strategy Programs and ESG teams

E-mail

Addresses

The team uses the following contact e-mails to enable program members and anyone interested to directly contact the team. Emails are handled with GitLab Service Desk, which allows to collaboratively manage the inbox.

Program e-mails:

  1. opensource@gitlab.com: GitLab for Open Source Program
  2. education@gitlab.com: GitLab for Education Program
  3. contributors@gitlab.com: Used for the Co-create and Notable Contributor programs (this is a shared inbox for all contributors’ requests).

Outreach campaigns

The Developer Relations Program Managers are responsible for email outreach campaigns to their program members.

  1. File an Marketing Operations issue to create a list of all known program members in existing databases. Given constraints in database segmentation, this list must be generated from leads that have been converted and contacts directly associated with institutions, communities or companies that have already signed-up for one of our existing programs including the GitLab for Education Program, GitLab for Open Source Program or GitLab for Startups program.
  2. File a one-time email request issue to send the initial program email to the above list. The initial program email must be sent by a campaign manager to ensure that the email is properly staged and follows existing protocols.
  3. Once the list is generated and initial program email is sent, the Developer Relations DRI for outreach emails will receive access to Marketo and permission to send email campaigns to the above specified list. The Developer Relations DRI will use the initial email as a template to stage and send all future outreach emails.

The following protocols must be follow:

  1. Developer Relations program outreach emails will only be sent by the DRI using the initial program email as a template.
  2. Developer Relations program outreach emails will only be sent at a maximum frequency of once a month.
  3. Developer Relations program outreach emails will only contain content relevant directly the Developer Relations Program. Content can include: call to action to engage, announcements regarding program requirements or terms, or newsletter type content.

Social Media

To request program content to be posted through GitLab social media channels use this form.

EveryoneSocial allows to increase reach by empowering GitLab team members to share content through their personal channels. Add the content on EveryoneSocial Developer Relations channel and any other relevant.

Newsletters

None of the programs have currently a newsletter. PMs leverage the following newsletters to raise awareness of our programs, both internally and externally:

  • Company Newsletter: Sent to GitLab team members to communicate relevant updates twice a month. To add program-related content, add a comment in the current issue, following these instructions.
  • Customer Newsletter. Sent to customers on the 4th Thursday/Friday of the month. To add program-related content, add a comment in the current issue attached to the FY26 epic as per process.

Content

GitLab Blog posts

The Content Marketing team manages the GitLab Blog and can review blog pitches, provide editorial feedback, and schedule the post for publication and outreach. To submit a blog post pitch see the GitLab Blog handbook page instructions and use the relevant blog pitch template.

Creating new assets

The Brand Creative team can help design, create, support and review assets such as designs, tanuki tabs, swag, and more. To submit a creative request use the relevant template.

The Developer Advocacy team creates content tailored for developer audiences. You can send a request by submitting an issue as per the team’s process.

You can also create your own content, ensuring alignment with GitLab’s brand guidelines. To create assets, use Canva under the GitLab team account, which provides access to Business features and includes a brand kit. All assets should be at a minimum reviewed and approved by the Brand Creative team.

Asset Library

Check the program pages to find each program specific resources. Generally:

  • Canva assets can be found in the Strategy Programs folder. Please tag as draft WIP resources or not yet approved.
  • Design assets for the programs can be found in the Corporate Marketing Project using the ‘find file’ feature and searching for the name of the program.

Measurement

Engagement tracking

Any link or QR code shared through any of our activities must be tracked. This allows to measure clicks/scans as well as traffic generated for reporting.

The team uses Hovercode to shorten links, create QR codes, and generate engagement analytics. User/password to access the platform is stored in the Marketing 1password vault.

GitLab Support

To open a ticket with GitLab Support on behalf of a program member, fill an internal request choosing option “Create a support ticket on behalf of a prospect or customer”.

The recipient is the program member and therefore they will see the information in the fields highlighted, and receive ticket responses directly.

We use this process for:

  • Manual credit card validation for program members

Contributor Success requests

The Strategy Programs team requests specific tasks from the wider Contributor Success team. Open a new issue in the Contributor Success team-task project, which will ping the Contributor Success team to triage.

License grants

Automated application workflow

  1. Application: An applicant initiates verification process in the Customer portal for eligibility verification.
  2. Verification: Proxi.id, the Customers portal and/or the strategy programs team verify applicant’s eligibility.
  3. Booking: Successfully verified applicants receive an email with instructions for activating a complimentary GitLab license. Applicants receive a coupon code and enter this code during checkout at a program-specific checkout page in the GitLab Customers Portal.
  4. Provisioning: A subscription license is provisioned through the web direct process on the GitLab Customers Portal.
  5. Compliance: Stage handled by Sales-Support and Billing Ops teams.
  6. Renewal: Program members receive notifications when their subscriptions are due to expire. They also receive instructions for renewing those subscriptions.
  7. Support: New applicants and renewing members can seek support for issues with the application process and other program requests.
Expand detailed workflow

Application

Customers Portal

Customers are directed from the landing page to the corresponding program page in the Customers portal (Open Source or Education). If a customer doesn’t have a Customers portal account yet, they must create it before proceeding.

Verification

The GitLab for Education program uses Proxi.id to verify the program applicant belongs to an academic institution. Escalations requiring immediate support from Proxi.id can be made to gitlab-support@proxi.id.

The verification process differs by program. See these handbook pages for more detail:

Upon successful verification, applicants receive an email with instructions for obtaining their licenses. These instructions include a unique coupon code generated by the fulfillment team at GitLab (via a coupon code generator). The DRI for the coupon code generator is the fulfillment team.

Exceptions

When automated verification fails, it is possible for a PM to approve an exception and grant a license manually. Use this file to retrieve and assign a code manually. Ensure it is marked as dispatched and fill columns E and F accordingly.

To generate new coupon codes, open an issue (example) in the customers-gitlab-com project.

Booking

Successful applicants receive an email through the GitLab Customers Portal. This email contains a direct link to a program-specific page in the Customers Portal. These program-specific pages are not discoverable in the GitLab Customers Portal; they are only accessible through links in success emails. See GitLab’s internal handbook for links to these portals.

During the checkout process:

Provisioning

Licenses are provisioned directly during process through the WebDirect flow and according to one of the following SKUs:

  • [EDU Program] SaaS - Ultimate (formerly Gold) - 1 Year [EDU Program] SaaS - Ultimate - 1 Year

  • [EDU Program] SaaS - Ultimate (formerly Gold) w/ Support - 1 Year [EDU Program] SaaS - Support - 1 Year [EDU Program] SaaS - Ultimate - 1 Year

  • [EDU Program] Self-Managed - Ultimate - 1 Year [EDU Program] Self-Managed - Ultimate - 1 Year

  • [EDU Program] Self-Managed - Ultimate w/ Support - 1 Year [EDU Program] Self-Managed - Ultimate - 1 Year [EDU Program] Self-Managed - Support - 1 Year

  • [OSS Program] SaaS - Ultimate (formerly Gold) - 1 Year [OSS Program] SaaS - Ultimate - 1 Year

  • [OSS Program] SaaS - Ultimate (formerly Gold) w/ Support - 1 Year [OSS Program] SaaS - Support - 1 Year [OSS Program] SaaS - Ultimate - 1 Year

  • [OSS Program] SaaS - Ultimate (formerly Gold) w/ Support - 3 Year [OSS Program] SaaS - Support - 3 Year [OSS Program] SaaS - Ultimate - 1 Year

  • [OSS Program] Self-Managed - Ultimate - 1 Year [OSS Program] Self-Managed - Ultimate - 1 Year

  • [OSS Program] Self-Managed - Ultimate w/ Support - 1 Year [OSS Program] Self-Managed - Support - 1 Year [OSS Program] Self-Managed - Ultimate - 1 Year

  • [OSS Program] Self-Managed - Ultimate w/ Support - 1 Year [OSS Program] Self-Managed - Support - 3 Year [OSS Program] Self-Managed - Ultimate - 3 Year

Compliance

Sales-Support and Billing Ops handle compliance-related issues. This stage results in granting the license and notifying the customer of how to access the licenses. The Strategy Programs team ensures compliance with Program Agreements.

In cases where the Strategy Programs team believes a program member’s actions violate the terms of a Program Agreement, team members will report the suspected violation by opening a Legal and Compliance issue. The Strategy Programs team will then collaborate with GitLab’s Legal team to determine the most appropriate method of assessing the issue.

Redress

If the violation is curable, the team will enact the following procedure to begin redress and ensure compliance.

First, the team will notify the program member of the suspected violation using this template. The purpose of this message is to:

  • Serve as formal notice that under the terms of an applicable Agreement the program member’s current use of the licenses granted is not in compliance with the terms of the applicable Agreement
  • Signal the beginning of the 30-day cure period, by the conclusion of which the program member must rectify the failure
  • Express interest in and commitment to working with the program member to remedy the situation
  • Offer to meet with (or communicate asynchronously with) the program member to answer additional questions about the member’s use of GitLab under the terms of the Program Agreement

At the conclusion of the cure period:

If the program member remedies the situation, then no further action is necessary and the program member can continue using its GitLab subscription.

If the program member does not remedy the situation, then GitLab will terminate the subscription license granted under the terms of the applicable Agreement.

Revocation

Certain situations may warrant immediate revocation of a program member’s subscription license. In those cases, GitLab will use best efforts to notify the program member prior to revocation subject to the terms of the applicable agreement.

To revoke a subscription license, engage GitLab’s Sales Support team through Salesforce:

  1. Locate the subscription associated with the license in question
  2. Chatter Deal Desk to request this subscription be “debooked”, which will revoke the associated license

Renewal

Applicants renewing their program memberships must re-apply to the respective programs to ensure continued eligibility. To do this, they use the same application forms they used when initially enrolling in the program, with the only difference of the links used in the booking stage.

Expand common issues

Common Issues

Each step of the automated application workflow has different set of potential errors and related support workflows.

Verification - Proxi.id Application

  • Never received success email
    Contact education@gitlab.com or opensource@gitlab.com
  • Something doesn’t work while visiting the Customers portal
    Contact education@gitlab.com or opensource@gitlab.com
  • Something doesn’t work during the verification process on the Proxi.id portal
    Contact Proxi.id team at gitlab-support@proxi.id

Booking - GitLab Customers Portal

Fulfillment | GitLab Customers Portal

  • Customers Portal problems after coupon code redemption succeeds.
    Open Support Ticket Issues with billing, purchasing, subscriptions, or licenses.
  • Incorrect number of seats or incorrect hosting type (self-managed or Saas) chosen, and the license has already been granted, the application will need to obtain an add on quote to change the license parameters
    Contact education@gitlab.com or opensource@gitlab.com

The Strategy Programs team is responsible for all processes involved in issuing licenses for GitLab’s Strategy Programs including GitLab for Education and GitLab for Open Source.

Salesforce

Chatter the Sales team

Chatter is the primary method of communication between users and groups in Salesforce. Chatter can occur at Account or Opportunity level. Chatter notifications can be found on your individual’s home tab in Salesforce.

  • When an individual is chattered the message will appear both at the top of the object from which the chatter initiated (Account or Opportunity) and it will appear in the Chatter tab of Salesforce.
  • In order to chatter someone directly you can type @{NAME} in the chatter window and select the name of the person or group you wish to chatter.
  • For most questions related to the EDU-OSS workflow, chatter @Sales-Support, for example, if you need to merge duplicated accounts (make sure the domain and account names are the same)

Close expired renewals

The sales team might tag a Program Manager in expired opportunities that were never processed.

  1. On the opportunity page, click Edit
  2. Update the Close Date to today’s date.
  3. Change the Stage to 8- Closed Lost
  4. Update the Closed Lost/Unqualified Detailed section to other and add details “Educational Institution did not move forward with renewal”
  5. Save the opportunity details.
  6. Close the case in the Case Queue.

Edit an address

  1. Navigate to the Account view in Salesforce. Scroll down to the Address Information, Billing Address. The Billing Address can also be accessed from the Contact view.

  2. Click the edit button to edit the address. Click OK to save the changes. The address is updated for the Account, Contact and Opportunity.