Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Community Advocate Bootcamp Checklist

Bootcamp Checklist for Training of New Community Advocates

Your manager should create an issue with this checklist on the community advocacy issue tracker for you as part of your onboarding. This list looks strange in this handbook because it is formatted to be copy-pasted into an issue and then render properly there.

The topics are generally ordered by priority in which they need to be tackled, but feel free to work on later things in the list when you are waiting on something.

We need to keep iterating on this checklist so please submit MR's for any improvements
that you can think of. The file is located in
in the [www-gitlab-com]( project. If an item does not start with a role or name of someone else, it's yours to do.

**Goal of this entire checklist:** Set a clear path for Community Advocacy training

### Stage 0: Complete general onboarding to have all necessary accounts and permissions

- [ ] **Done with Stage 0**

_Typically completed within first week_

1. [ ] General expectations: it is expected that you will _start_ to tackle Stages 0, 1, 2, and 3 as early as your first week, but you are not expected to complete all items for some number of weeks. We believe that you often learn best and fastest by diving into (relatively easy) tickets, and learning by doing. However, this has to be balanced with making time to learn some of the tougher topics. The expectation is therefore that you are sufficiently advanced in your onboarding by the end of your first week, that you can answer 2-5 "simple" tickets. Over the following weeks, your manager will set higher targets for the number and difficulty of tickets to be tackled, but you should always have about 2-3 hrs per day to spend on working through this bootcamp. Some days it will be less, some days it will be more, depending on ticket load and how deep "in the zone" you are in either the bootcamp or the tickets you are responding to; but an average of 2-3 hrs per day should allow you to complete everything through to the end of Stage 6 within about four weeks.
1. [ ] General Onboarding Checklist: this should have been created for you on [the People Ops Employment issue tracker]( as an issue by PeopleOps when you were hired.
   1. [ ] Finish every item on that list starting with `New team member:` until you are waiting for someone to answer a question or do something before you can continue that list.
   1. [ ] Start with Stage 1 here, but also with the first steps in Stage 2 and Stage 3.
   1. [ ] Check back daily on what was blocking you on your General Onboarding Checklist until that list is completely done, then focus on this one.

### Stage 1: Become familiar with `git`, GitLab basics, and start exploration of Zendesk.

- [ ] **Done with Stage 1**

_Typically started in first week, completed by end of second week_

## Zendesk:

1. [ ] Check with your manager that you've been given Agent Access to the Community Advocate Zendesk instance.
1. [ ] Quickly check out your Zendesk account to confirm you can login. Explore which platforms are piped into the Zendesk ticket views.
1. [ ] Under your profile on Zendesk, it should read `Admin`. If it reads `Agent` or `Light Agent`, inform your manager.
1. [ ] Add a [profile picture]( to your Zendesk account
1. [ ] [Add Facebook to one of your personal views on Zendesk](/handbook/marketing/community-relations/community-operations/tools/zendesk/#view-limits-workaround).
1. [ ] Open an [Access Request](/handbook/business-ops/team-member-enablement/onboarding-access-requests/access-requests/)to be added as a ['Light Agent' on the Support Zendesk Instance](/handbook/support/internal-support/#viewing-support-tickets). Advocates use this instance to check in on support tickets inquired about over Twitter.

## Git and GitLab Basics:

If you are already comfortable with using Git and GitLab and you will be able to
retain a good amount of information by just reading and watching through, that is
okay. But if you see a topic that is completely new to you, stop the video and try
it out for yourself before continuing.

Cover these topics on the [GitLab University](

1. [ ] Under the topic of Git
  1. [ ] [About Version Control](
  1. [ ] [Try Git](
1. [ ] Under the topic of GitLab Basics
  1. [ ] All the [GitLab Basics]( that you don't feel comfortable with. If you get stuck, see the linked videos under GLB in GitLab University
  1. [ ] [GitLab Flow](
  1. [ ] Take a look at how the different GitLab versions [compare](
1. [ ] Any of these that you don't feel comfortable with in the [user training]( we use for our customers.
  1. [ ] ``
  1. [ ] ``
  1. [ ] ``
  1. [ ] ``
  1. [ ] ``
  1. [ ] For the rest of the topics in `user training`, just do a quick read over the file names so you start remembering where to find them.
1. [ ] Get familiar with the services GitLab offers
  1. [ ] The differences between [CE and EE](

Learn more about [GitLab vs. GitHub]( and others:

1. [ ] [#GitChallenge Blog - Comparison Chart](
1. [ ] [GitHub-GitLab Comparison]( 
1. [ ] [GitHub Actions Gaps](
1. [ ]  New Comparisons - [](, [Launch Darkly](, [BuildKite](

### Stage 2: Installation and Administration basics

- [ ] **Done with Stage 2** 

_Typically started in first week, completed by end of third week_

#### Goals

- Be prepared to reproduce issues that our users encounter.
- Be comfortable with the different installation options of GitLab.
- Have an installation available for reproducing customer bug reports.

#### Installations

You will install GitLab using Omnibus, which packages services and tools required to run GitLab.

Use the [GitLab Installation Guide]( for step-by-step directions on the installtion process.

The [Omnibus GitLab Docs]( are a good place to start if you have questions. 

1. [ ] Set up your test environment
  1. [ ] Create a non-root user
  1. [ ] Add your public SSH key to `authorized_keys` for the created user
  1. [ ] Optional: Disable password login
  1. [ ] Optional: Disable root SSH login
1. [ ] Install GitLab via [Omnibus](
  1. [ ] Populate with some test data: User account, Project, Issue
  1. [ ] Backup using our [Backup rake task](
  1. [ ] Delete the test data
  1. [ ] Restore backup using our [Restore rake task](
  1. [ ] Keep this installation up-to-date as patch and version releases become available, just like our customers would.
1. [ ] Ask as many questions as you can think of on the `#questions` chat channel

### Stage 3. Community Interaction

- [ ] **Done with Stage 3**

_Typically started in first week, and completed by the end of the fourth week_

#### Goals

- Have a good understanding of ticket flow through Zendesk and how to interact with our various channels
- See some common issues that our customers are facing and how to resolve them.
- Learn about the community advocacy process at GitLab.

#### Initial Zendesk training

1. [ ] Watch the [Zendesk Support Overview training video]( for an overview of how Zendesk functions. Note you will need to register on before viewing.
1. [ ] Review additional Zendesk resources
  1. [ ] [UI Overview](
  1. [ ] [Updating Tickets](
  1. [ ] [Working w/ Tickets]( *Read: avoiding agent collision.*
1. [ ] Set up 1 or 2 calls with a Community Advocate and ask them to share their screen to walk you through each Zendesk view.
  1. [ ] On this call, also ask the Advocate to explain how we use Zapier integration with our Zendesk views.
*Congratulations. You now have your Zendesk Wings*

From now on you can spend most of your work time answering tickets on Zendesk, try to set aside 2 hours per day to make it through **Stage 4-6** of this list. Never hesitate to ask as many questions as you can think of on the `#devrel` chat channel

#### Learn about raising issues and fielding feature proposals

1. [ ] Understand what's in the pipeline and proposed features at GitLab: [Direction Page](
1. [ ] Practice searching issues and filtering using [labels]( to find existing feature proposals and bugs
1. [ ] If raising a new issue always provide a relevant label and a link to the relevant ticket in Zendesk
1. [ ] Add [customer labels]( for those issues relevant to our subscribers
1. [ ] Take a look at issues with ["Accepting merge requests" label]([]=Accepting%20merge%20requests) - Issues opened for contribution from the wider community.
1. [ ] There is a limited number of features or tasks that the team can work. Take look on how we do our best to [prioritise](
/handbook/product/#prioritization) features. 
1. [ ] If there's a more than 1 year old issue, perhaps reach out to the product team regardless, as it might be possible that things have changed and the issue can either be milestoned or closed.
1. [ ] Take a look at the [existing issue templates]( to see what is expected
1. [ ] Raise issues for bugs in a manner that would make the issue easily reproducible. A Developer or a contributor may work on your issue.
1. [ ] Set up [Google search shortcuts](/handbook/tools-and-tips/searching/) to make it easier to locate docs and issues to share with the community 
1. [ ] Schedule a call with an advocate to discuss how the GitLab community uses issues to report bugs they find. Discuss strategies for using issues as a place to research answers and support for community members.

#### Explore the Community Relations Subgroups and Projects

1. [ ] Read the [Issue Board Documentation]( to learn how issue boards are used within GitLab.
1. [ ] Review the different projects on the [Community Relations Subgroupds and Projects]( These subgroups and projects track issues and MRs that the team is working on. 
1. [ ] Review the [Community Advocacy Issue Board]([]=Community%20Advocacy). This board holds issues specific to the advocates team. Each should be labeled with the 'Community Advocacy' tag. Advocates use 'status::plan' and 'status::wip' tags to track current work.
1. [ ] Look over the advocate issue boards for [Merchandise]([]=Merch), [Open Source]([]=Open%20Source), and [Education]([]=Education).
1. [ ] Other Community Relations issue boards are helpful to grow your understanding of larger team projects and goals. 

#### Learn about the Community Advocacy process

Zendesk is our Community Advocacy Centre and our main communication line with our customers. We communicate with customers through several other channels too.

1. [ ] Ask a few community advocates if they would be willing to do a 45 minute screen share with you as they answer tickets on Zendesk, thinking out loud as much as they can and answering your questions. Continue with the rest of the list while you wait for these to get scheduled.
  1. [ ] call with ___
  1. [ ] call with ___
  1. [ ] call with ___
1. [ ] Dive into our ZenDesk support process by reading how to [handle tickets](/handbook/marketing/community-relations/community-advocacy/#zendesk)
1. [ ] Start getting real world experience by handling real tickets, all the while gaining further experience with the Product.
  1. [ ] First, learn about our support channels that are handled by the [Community Advocacy team](/handbook/marketing/community-relations/community-advocacy/)
  1. [ ] Start with [Twitter](/handbook/marketing/community-relations/community-advocacy/#twitter)
  1. [ ] Continue on to [Disqus](/handbook/marketing/community-relations/community-advocacy/#disqus)
  1. [ ] Continue on to the [community@](/handbook/marketing/community-relations/community-advocacy/#community-email) email
  1. [ ] Continue on to [facebook](/handbook/marketing/community-relations/community-advocacy/#facebook)
  1. [ ] Continue on to the [GitLab forum](/handbook/marketing/community-relations/community-advocacy/#gitlab-forum)
  1. [ ] Read about the [other channels](/handbook/marketing/community-relations/community-advocacy/#specific-channels) the Community Advocacy team supports
1. [ ] Read the best practices in our forum. Generally, we direct technical support questions to the forum to be able to debug them. It's hard to debug over Twitter.
1. [ ] Read the [instructions]( for a user to contact support. Generally, we direct paid customers to open a support ticket at []( For [free plan users](, we direct them to the [GitLab Forum](
1. [ ] Check out your colleagues' responses
   1. [ ] Read through about 20 old tickets that your colleagues have worked on and their responses
1. [ ] Take a look at the [ Team page]( to find the resident experts in their fields
1. [ ] Learn about our [mentions-of-gitlab](/handbook/marketing/community-relations/community-advocacy/workflows/inactive/) Slack channel
  * This tracks all channels that are not routed through ZenDesk
  * HackerNews is routed through this channel - This is the top priority channel
- [ ] Block off your calendar to anticipate for [release posts](/handbook/marketing/community-relations/community-advocacy/#release-day-tasks)
  - They occur regularly every 22nd in the month, just like each GitLab release.
  - Take a look at the [latest release post](
- [ ] Order, expense, and read the Art of Community by Jono Bacon ([Amazon Link](
1. [ ] Schedule a call or reach out via slack to advocates at any point with questions on the workflow or with a request to walk through a few ticket examples.
1. [ ] Review the [Community Advocate issue board]([]=Community%20Advocacy) and review current projects the team is working on.

#### Learn about handling our diversity sponsorship program

1. [ ] Read about our [Diversity Sponsorship Program](
1. [ ] Take a look at the [Diversity Sponsorship applications](
1. [ ] Discuss with your trainer what qualifies an event for the diversity sponsorship program. If you have any further questions, feel free to ask the Evangelist Program Manager for the details.
1. [ ] Memorize our sponsorship acceptance/declination [email templates](

#### Learn about handling swag at GitLab

We use Shopify for [our storefront]( and [Printfection]( for sourcing swag.

1. [ ] Review the general [Merchandise Workflow](/handbook/marketing/corporate-marketing/merchandise-handling/)
1. [ ] Learn about our [MVP appreciation gifts](/handbook/marketing/corporate-marketing/merchandise-handling/#mvp-appreciation-gifts)
1. [ ] Learn about the process of [Swag requests](/handbook/marketing/corporate-marketing/merchandise-handling/#swag-requests)
1. [ ] Join `#swag` slack channel 

### Stage 4. Gathering Diagnostics

- [ ] **Done with Stage 4**

_Typically do this around the third week._

**Goal** Understand the gathering of diagnostics for GitLab instances

1. [ ] Learn about the GitLab checks that are available
    1. [ ] [Environment Information and maintenance checks](
    1. [ ] [GitLab check](
    1. [ ] Omnibus commands
        1. [ ] [Status](
        1. [ ] [Starting and stopping services](
        1. [ ] [Starting a rails console](

### Stage 5. Optional Advanced GitLab Topics

Discuss with your training manager if you should stop here and close your issue
or continue. Also discuss which of the advanced topics should be followed. Do
not just do all of them as they might not be relevant to what customers need
right now and can be a significant time investment.

These are some of GitLab's more advanced features. You can make use of to understand the features from an end-user perspective and then use
your own instance to understand setup and configuration of the feature from an
Administrative perspective

- [ ] Set up and try [Git LFS](
- [ ] Get to know the [GitLab API](, its capabilities and shortcomings
- [ ] Learn how to [migrate from SVN to Git](
- [ ] Set up [GitLab CI](
- [ ] Create your first [GitLab Page](
- [ ] Set up a [GitLab Development Kit]( instance
- [ ] Get familiar with the GitLab source code by finding the differences
between the [EE codebase]( and the [CE codebase](
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license