Community Operations

1. You are here:
2. Handbook
3. Marketing
4. Community Relations
5. Community Operations

Maintained by:

John Coghlan

@johncoghlan

On this page

• Our mission
  • Partnership
  • Tooling
    • Community Operations Tool Stack
      • Community Operations Tool Stack (deprecated)
      • Tools pending addition to tech stack
      • Other tools we rely on
    • Adding a new tool to the Community Relations tool stack
  • GitLab's Community
• Community Operations Work
  • How to Use the Community Operations Issue Board
  • How to Use the community-ops Label in GitLab
• Team Budgets
  • Allocadia Workaround
  • How we create our annual budget
  • Reallocation and adjustments
  • Managing Expenses and Actual Spend
    • Procurement for Community Team
    • Tracking swag giveaway expenses
  • Community Event Sponsorship
    • How to submit a community event sponsorship request
    • How we assess requests
• Community Operations Response Channels
• Relevant Processes
  • Social Media Team
  • Expert Responses
    • Examples of when to involve an expert
    • Slack Template for Involving Experts
  • Forum Uses
    • Announcements
    • Announcement Components
    • Banner (optional)
    • Announcement Draft Post
    • gitlab-blog forum bot
  • Support for Education, Open Source and Startup Programs
    • Common Community Program metrics

Our mission

GitLab's Community Operations Program is responsible for developing and maintaining the infrastructure and resources to support the Community Relations team and the GitLab community at large. In this, we help support GitLab's greater mission of 'everyone can contribute' by encouraging the wider GitLab community through process and opportunity.

Partnership

The mission of this program is to act as a partner to all Program Managers in the Community Relations team to define, implement and refine KPIs/PIs to measure and report the success and effectiveness of our community programs. We work together with the Community Relations team’s Program Managers to produce regular, engaging content to highlight their programs and attract new contributors.

Community Relations Handbook

The Community Operations function also works closely with the Marketing Operations, and Data and Analytics teams.

Tooling

Community Operations defines and maintains the tool stack required to measure and interact with the wider GitLab community. The Community Program Manager acts as the DRI for the Community Relations team’s webpages on about.gitlab.com. This program also supports the Open Source and Education teams by processing program applications and renewals. Ultimately, we are working towards a process to fully automate this.

Community Operations Tool Stack

These are the tools the Community Relations team is the DRI for:

Community Operations Tool Stack (deprecated)

This overview is currently being deprecated as we attempt to migrate from the manually-generated list to one automatically-generated from the data/tech_stack.yml file. Please use the automatically-generated table instead

Tools pending addition to tech stack

The Community Relations team is also the DRI for these tools which are pending addition to the tech stack:

Other tools we rely on

These are the tools that are essential to some Community programs, but the Community Relations team are not the DRI for:

Adding a new tool to the Community Relations tool stack

1. Please follow the procurement process as you would for adding any new tool to GitLab's tech stack.
2. Ensure that the group_owner field on the tech stack file entry is set to Community Relations. This will make the tool to be automatically listed on the Community Relations toolstack.

GitLab's Community

The Community Operations Program curates and maintains documentation for any team member to productively engage with the wider community. When necessary, we engage with specialists within GitLab to provide responses and listen to our community’s feedback on The GitLab forum, the GitLab blog and Hackernews.

The Community Operations Manager reports to the Director of the Community Relations Team.

Community Operations Work

You can find the Community Operations Program peppered throughout the Community Relations handbook, processes, and projects.

In order to loop in Community Operations on GitLab.com, please use the community-ops label.

Everything labeled community-ops is organized on the Community Operations Issue Board.

How to Use the Community Operations Issue Board

How to Use the community-ops Label in GitLab

Please use the community-ops label only when there is an action item needed from the Community Operations Manager.

If you think an issue or MR is a "nice to know" for the Community Operations Manager, feel free to loop them in (@lindsayolson) via a comment instead.

Team Budgets

We use Allocadia to manage team budgets. Due to a limited number of seats being allocated to the Marketing team, only @dplanella and @c_hupy have access to the tool from the Community Relations team (sign-in from Okta is required). They are responsible for coordinating with the Community Relations team to make sure that forecasts are properly added to Allocadia.

Quarterly Budget Planning Issues. As each quarter begins, the Community Relations team creates a new issue using the quarterly_budget_plan issue template in the Community Ops project.

Annual Budget Planning Issues. In preparation for the year ahead, the Community Relations team creates a new epic that then links to the quarterly planning issues.

Current epic: FY22 Community Relations Budget Planning.

Allocadia Workaround

As a workaround for easier collaboration, those with Allocadia access do regular exports of the budget into a Google Spreadsheet by downloading the Community Relations budget by clicking on: Export current view. These exports generally happen monthly as we reconcile actual spend. If a team member needs a more recent snapshpt, please mention @johncoghlan and @c_hupy on the #community-relations Slack channel to request an export.

GitLab team members can find the exported Community Relations budget by searching for the FY22 Community Relations Budget export document in Google Drive.

How we create our annual budget

Like other teams at GitLab, the Community Relations team proposes an annual budget to cover the costs necessary for each of its subprograms. This total annual budget is then proposed to Marketing leadership, and to the e-group, for approval.

Once approved, the Community Relations team then forecasts how much of the total annual budget will be spent each quarter, and if possible, which month each spend will occur. The total annual budget cannot be adjusted except for in special circumstances with approval of the e-group.

Reallocation and adjustments

Adjustments between the quarterly forecasts (moving budget from one quarter to another), can occur up until the specific quarter's forecasts are locked in. This occurs on the last day of the previous quarter (eg. the FY22 Q2 forecast is due on April 30th).

Once a quarter's forecast has been locked, no further adjustment to that quarter's spending is allowed. For example, if the forecasted amount for that quarter is not used up, then that amount is "lost" and cannot be reallocated to another quarter.

Line-item adjustments can occur once the quarterly forecast is locked. To do so, a request needs to be submitted and approved by @johncoghlan or @c_hupy for the Community Relations team.

Managing Expenses and Actual Spend

Each month, the Community Relations team program managers meet with our parters in Finance to review actual monthly expenses during the monthly Community Relations Accruals meeting. This process allows us to accurately report our team expenditures vs budget forecasts.

Costs over $5000 are allocated out month by month for a specified amount of time by the appropriate Community Program Manager.

Costs under $5000 do not need to be allocated over time, and will be removed from the budget all at once.

Procurement for Community Team

We use Coupa for most procurement requests. For more information, please reference the Procurement Process handbook.

All invoices require a PO number, so vendors must be given the appropriate PO number to include in their invoice. The PO numbers are assigned by the Procurement team. Invoices received without the correct PO number will be rejected and must be resubmitted with the relevant PO number included. For questions, please ask the Procurement Team on Slack: #procurement.

Here are the PO numbers that belong to our team so far:

• EDU/OSS: PO #40

When filing a procurement issue, you may also be asked for an Allocadia ID number. To get this ID, ask someone with Allocadia access to fill out the details in the line item. Once this is done, an ID will be populate in the top left hand corner of the details panel, where it says Line Item ID.

Tracking swag giveaway expenses

To help our finance team keep track of community swag giveaways, giveaways in Printfection that support Community Relations programs and events should add Community: as a prefix to the campaign title. Ex: Community: GitLab Heroes + Superheroes Swag.

We use the campaign tag swag_community to track our spend in the budget.

There is a recurring maintenance cost of the community program's campaigns on Printfection. Printfection does shipping and handling through prepaid amounts of fixed increments, so the charge won't happen often but will come as part of the costs for the campaigns we run.

Community Event Sponsorship

This section details how we make decisions about sponsoring community events.

Events Decision Tree:

How to submit a community event sponsorship request

To submit a community event for support or sponsorship:

1. Review our events decision tree to ensure you are directing your event inquiry to the appropriate team.
2. Submit an issue using the sponsorship-request template.
3. For Service Desk or other auto-generated issues that contain sponsorship requests, we will retroactively apply the 'sponsorship-request' to the issue. The process for updating an issue with no template to the 'sponsorship-request' template is: copy text from original issue, assign 'sponsorship-request' template to issue, paste text from original issue into the appropriate field at bottom of template, update remaining fields.
4. GitLab's Open Source Program Manager will review the request and follow up with the event contact.

How we assess requests

We ask the following questions when assessing an event:

• Will there be a GitLab speaker? We do not require a speaker slot in return for sponsorship but we do prioritize events where the audience will be hearing about GitLab - either from a GitLab team member or a member of the wider GitLab community.
• What type of people will be attending the event? We prioritize events attended by diverse groups of developers with an interest in DevSecOps, Cloud Native, Kubernetes, Serverless, Multi-cloud, CI/CD, Open Source, and other related topics.
• Will we be able to interact with attendees? We prioritize events that provide opportunities for meetings, workshops, booth or stands to help people find us, and other interaction with attendees.
• Where will the event be held? We aim to have a presence at events around the globe with a particular focus on areas with large GitLab communities and large populations of developers.
• Is the event important for industry and/or open source visibility? We prioritize events that influence trends and attract leaders within the developer and open source communities. We also prioritize events organized by our strategic partners.
• What is the size of the opportunity for the event? We prioritize events based on audience size, the number of interactions we have with attendees, and potential for future contributions to GitLab from attendees.

Each question is graded on a scale of 0-2. We then tally the scores and assign the event to a sponsorship tier.

• Events scoring below 5 are not eligible for sponsorship.
• Events scoring 6-8 are eligible for GitLab swag for attendees and other in-kind sponsorship.
• Events scoring 9 or above are eligible for financial support.

We ask these questions and use this scorecard to ensure that we're prioritizing GitLab's and our community's best interests when we sponsor events.

If you have questions, you can always reach us by sending an e-mail to community@gitlab.com.

Community Operations Response Channels

Relevant Processes

It is not uncommon that the Social Media Team, and Communications Team at GitLab reaches out to Community Operations. Because of Community Operaions' response channels, and nature of the program, Community Operations has a unique view of the community's sentiment and tone. This means that the Community Operations Manager uses the following resources and handbook pages as needed, when partnering with Social and Comms to ensure a quality response back to our community in times of crisis or gerneral low sentiment and tone.

Check out the social, community operations, and expert shared Community Management practices

Social Media Team

Social Media Guidelines

Expert Responses

Occasionally the Community Operations Manager will encourage GitLab Team Members, as experts, to engage with the wider GitLab community following our Team Member Social Media Guidelines as well as these additional flexible guidelines, listed here:

1. Experts are encouraged be themselves, while using the GitLab Writing Style Guidelines - we always want to be personable and human in our online presence.
2. Engage as yourself whenever possible. (ex. use your personal Twitter handle)
3. Always try and link to relevant documentation, issues, handbook pages, forum topics and other resources.

Examples of when to involve an expert

• Technical questions or comments on a GitLab blog post
• HackerNews questions about a strategic GitLab topic (e.g. CI, security) or misinformation about GitLab
• Forum topics re: specific use cases not covered in the docs or relevant product feedback

Slack Template for Involving Experts

@expert_username [LINK TO COMMUNITY COMMENT] Hello! An expert is needed to respond to this. Could you please answer on [name of social platform] using your own individual account? If you don't know the answer, could you share your thoughts and ping a specific expert who might? Or if there is a more appropriate channel to ask, could you point me in that direction? Thanks!

Forum Uses

Announcements

In the past the Product Management Team has sucessfully used the forum as a space to foster conversation and encourage feedback on changes to the GitLab product. Here is an example of when we changed our subscription model.

Announcement Components

Banner (optional)

Steps for bannering on Discourse

1. Download design component to your computer
2. In Discourse navigate to Admin Panel > Customize > Themes > Top Navbar
3. Under uploads, click the Add+ button
4. Add your design
5. Click Edit CSS/HTML
6. Add mini banner CSS:

   .mini-banner__image {
     height: 60.5px;
     width: 720px;
     background-image: url($mini-banner);
     background-size: 100% 100%;
     margin: 0 auto;
   }
   

7. Click After Header and add this div to make CSS work

   <div class="main-banner">
     <a href="https://forum.gitlab.com">
       <div class="main-banner__image"></div>
     </a>
   
     <a href="https://forum.gitlab.com/t/ci-cd-minutes-for-free-tier/40241" target="__blank">
       <div class="mini-banner__image"></div>
     </a>
   </div>
   

8. Slight modifications may be needed depending on the size of the image

Announcement Draft Post

Typically it is the task of the Product Manager or DRI to draft and wordsmith the announcement post. This will happen via an issue, so the forum DRI can simpy copy and paste the language into the forum draft verbatim.

In order to visualize and prepare for the upcoming announcement do this in the Staff category That way users won't be able to see the announcement before it's time, and the forum DRI will be able to add links to the Announcement's FAQ and/ or Blog post, as well as link to GitLab's Code of Conduct.

Steps for creating a draft post

1. Navigate to the Staff category
2. Click +New Topic
3. Paste in content/language from issue
4. Add approved suject line (this will end up being the URL)
5. Click Create topic
6. Share screenshot of topic draft in related issed since most Product Managers do not have permissions to visit the Staff category.

When it's time for the Draft post to "go live"

1. Click the big pencil next to the subject line
2. Choose appropriate category from the dropdown underneath the subject line

Optional steps are:

1. Change the topic owner from yourself to the Product DRI by clicking on the wrench icon on the right of the screen and select from dropdown
2. Change the timestamp by clicking on the wrench icon on the right of the screen and select from dropdown

gitlab-blog forum bot

The gitlab-blog user is used to automatically post new GitLab blogs as a new topic to the Community category. This process is controlled through Zapier. Zapier reads the blog RSS feed at https://about.gitlab.com/atom.xml and posts a new topic using the admin API key and gitlab-blog user for each new entry there.

The gitlab-blog credentials and admin API key are stored in the 1Password Marketing vault. Admins can directly edit the user in Discourse without login.

Support for Education, Open Source and Startup Programs

Community Operations supports the Education, Open Source and Startups Programs, and their Program Managers.

The Community Operations team helps process and manage program applications as per the community programs applications workflow.

Common Community Program metrics

Due to the similarity among our Community Programs' workflows and goals, the Community Operations team helps keep track of common community program metrics.