We try to get together every 9 months or so to get face-time, build community, and get some work done! Since our team is scattered all over the globe, we try to plan a different location for each Summit.
The goal of our Summits is to get to know the people in the GitLab community better. The better you know people the easier it is to collaborate. We want to build trust between groups.
You are encouraged to take pictures and post on social media. If you take pictures of people not on the podium please ask their permission. Please consider using the hashtag #GitLabSummit Our social media guidelines still apply.
All team members of the GitLab company, SOs, Core Team, contributors, customers, press, and anyone interested in joining.
The next summit coming up will be in May 2019 in New Orleans, Louisiana in the United States! All info to prepare for this will be on the project page as soon as we've signed with a hotel
Counting down to May 2019!
Summit in Cape Town, South Africa
Last August, in 2018, our team had grown to about 320 people. Over 260 of them came to Cape Town, South Africa. We had over 85 SOs present and were also joined by a handful of customers, our advisors, and investors.
In August 2018, the whole team had grown to 320 GitLabbers!
Summit in Crete, Greece
By October 2017 we had 200 team members and 65 significant others getting together in Greece to enjoy the beautiful islands of Crete and Santorini.
When October 2017 came around, the whole team already counted 200 GitLabbers!
Summit in Cancun, Mexico
In January 2017, we met in Cancun, Mexico, where roughly 150 team members and 50 significant others flew in from 35 different countries.
In January 2017, the whole team had grown to 150 GitLabbers!
Summit in Austin, Texas
In May 2016, our team of 85 met up in Austin, TX to see if they were (still) as awesome as they seemed on Google Hangout.
Here's some footage our team put together to show how much fun we had:
Back in May 2016, the whole team was a total of 85 GitLabbers
Summit in Amsterdam, the Netherlands
Here are some impressions from our second summit in October 2015.
Summit in Novi Sad, Serbia
First summit, less then 10 people attending; highlight was lunch at Marin's mom's home in October 2013.
Leisure time around the Summit
The GitLab Summit is a work trip, not an incentive trip
If you want to enjoy the resort facilities or the area around it, feel free to book an extra day or more before or after the summit
The Summit organization will plan "regular work time" for you to do regular work such as handling emails
When you sign up for the activities we plan for the non-work days, you agree to show up.
If you don't show up for the activity, you will be responsible for the costs involved for the seat you give up after the RSVP deadline has passed.
When you replied "Maybe" or didn't reply at all, you understand that there will not be a ticket booked for you and you won't be able to join the activitie(s).
Bring your significant other
Significant Others (SO) are very welcome to attend
One SO per team member
You are responsible for the SO you invite
Your SOs presence should not distract you from engaging with other team members and actively participating in Summit activities
SOs should do their best to get to know many people
SOs are welcome at all presentations, events, and meetings that are open to all team members
If you're having a meal with your SO, pick a table with more than two seats so you can invite others to join you
Having your children join you
Children are strongly discouraged from attending. We have observed from past summits that contributors who have chosen to bring children spend significantly less time collaborating with GitLab coworkers. Accordingly, we are requesting that if you must travel with family members you fully engage in as many group activities as you are physically able, invite team members to join you during meals, attend all company meetings, and recognize that the Summit is an investment in the continued growth of the organization.
Attending the summit is optional but recommended. Most people report it is great to get to know each-other better and the schedule is fun, about 90% of the team is able to attend.
The executive team is required to attend for the full duration of the summit.
Wear your name-tag when you're outside your room, including during excursions, meals, and on departure day.
Try to join different people every time we sit down for a meal
Try to form a personal bond with team members of other teams.
The summit is great for informal meetings and brainstorming, like User Generated Content discussions. People already know their team, so try to make UGC sessions cross functional.
Don't plan meetings and 1-1's with your own team at the summit, we already do these when we're not at the summit. It is OK to organize one dinner with the team.
Prior to the summit, ensure to communicate to any external stakeholders (i.e. candidates, customers, vendors, etc) that response time may be less reliable, as you will be out of the office and will not have as much access to email and calls.
Respect the laws and customs of the location we are visiting.
Health and safety
Look after your self during the summit and avoid summit burnout. It can be an exciting time with lots of new people to meet and things going on you want to take part in. Remember to take down-time if you need it to recuperate during the week rather than trying to burn the candle at both ends and risking exhaustion.
Every year about a third of us have some kind of flu after the summit, so please take infection prevention seriously.
Be respectful of other hotel guests (e.g. don't talk on your floor when returning to your room at night & keep your volume down at restaurants/bars).
Utilize the resources available to understand the safety and crime considerations in the location we are visiting. Examples are the UK's Foreign Travel Site and the U.S. State Department. If you are alarmed by what you are reading, please feel free to reach out to People Ops Team with your concerns. We also advise reviewing the data for countries you feel are safe. You may find that even the safest countries have warnings on crime and safety. Staying with a group and away from known dangerous areas is the most basic way of avoiding problems.
Great WiFi is essential to the success of the summit. We can't have everyone in one location and not have excellent internet.
Main room needs one access point for every 40 people attending in the main room and management, we have our own equipment but need to buy more.
We need two different uplinks from two different providers.
We need our own router between the uplinks and the WiFi.
We need wired connections to the WiFi access points.
We need to have WiFi working before the executive team arrives.
We need very reliable fast connections if we are livestreaming during the summit.
We need a map of the property with all wiring and access points drawn in 3 months before the summit starts.
Ensure there are large meeting rooms for team members to join work hours and presentations
Tip: Label your charger, or other belongings, with your name for easy return to owner in case you lose it
The following should be assigned and/or arranged a month before the Summit:
All interviews, presentations and content production
Who will be presenting and when & where they will be presenting
Projectors, wireless (non-hand-held) microphones, and any other (audio) needs
Recording equipment such as stage cam, audience cam, presentation feed etc.
An audio feed that goes directly from microphone into the recording
A program and manager for live streaming
The blog text for the presentation, including relevant materials shared after the presentation, as well as approval and a plan to publish the blog 24 hours after the presentation is given
GitLab Summits have variety of sessions: UGCs, workshops, presentations, etc. A summit isn’t a conference, its a "meeting of minds”. Its a place to connect and collaborate in an environment where everyone can contribute. We don’t present to our users and customers, they present to us.
UGC stands for “user generated content.” The goal is for a group to come together to produce something collectively. A UGC “user” can be anyone in the GitLab community: GitLabber, significant other, customer, contributors, etc. including “GitLab users” (e.g. someone who uses GitLab).
Content is generated from the discussion, not prepared ahead of time. 3. Each UGC has a google doc to capture notes. a. Pro tip: Set up offline access for Google Drive so you can take notes even if wifi is spotty. The doc is then ready to share once you can connect to the internet again. 4. Sharing in real-time is optional. a. Everyone can contribute, not everyone must contribute. b. Some folks prefer to listen. c. Some folks prefer to think about the session then add comments to google doc later.
Can be GitLab or non-GitLab related a. GitLab related: produce notes that can be shared. Decided later is any action needs to be taken. Create an MR together on-site. b. Non-Gitlab related: Just have a discussion about something you enjoy with other people who enjoy the same thing to build a relationship.
Preparation needed: a. A google doc for the session b. A facilitator
How to facilitate a UGC
Give a short introduction to the topic (about 2 minutes) for folks that may not be familiar.
Ask some questions to get people talking then let the discuss flow organically. Some example questions: a. Why did you come to this session? b. You mentioned X, can you tell us more about that? c. , do you have any thoughts on this topic?
Good to ask someone this if they’ve been quiet or haven’t participated yet. Some folks are waiting for an invitation to speak and will appreciate being asked specifically to share. Some folks will say, “no thanks” and prefer to listen. Both are ok. d. <name>, we’d like to hear what you have to say, but first let’s allow <name> finish their thought.
Good to interrupt someone who has just interrupted someone else so that everyone can contribute and one person doesn’t dominate the conversation.
The following are measures of a successful UGC: 1. Contribution: the more people contributing, the better.
Thorough notes: a Google Doc full of notes. There’s no expectation to act on the notes. Once the session is complete, you can decide if there’s a next action.
Relationship building: some UGCs won’t have a next-step action; they were simply opportunities for people who enjoy the same thing to build relationships. Examples might include board games, cooking, or mountain climbing.
Tangible artifacts: assets produced by the group (e.g. an MR, a demo, a diagram, a song, etc.)
Here's an overview of how this works during our summits.
We request everyone to send in topics to discuss during the sessions at the summit a few weeks out.
If you're suggesting a topic, we ask you to be the topic leader. This means the following:
You start the session with a short 2 minute verbal introduction, no preparation or presentation needed.
During the discussion you facilitate the conversation, meaning keeping it on topic, making sure everyone is heard, and asking relevant questions.
When time is up you give a short summary and thank the people that contributed relevant questions and answers.
After all topics are received, we send a survey to all attendees asking them to vote on the topics most interesting to them.
Once we've received all votes, after the deadline, we select the topics for the sessions.
Everyone signs up for sessions, we limit every session to 9 people maximum so that everyone can contribute.
We schedule 2, 4 hour blocks on separate days to have the sessions.
Within each 4 hour block we schedule 4 session blocks (with multiple topics in different locations during each block) with a short break of 15 minutes in between for a quick drink/snack or bathroom break.
A workshop is interactive training (e.g. Rails Girls, Kubernetes 101, Speaker Training, etc.)
Everyone can participate. It’s a workshop, not a presentation. Everyone in the room should be able participate. 3. Can be a small or large number of people. Larger groups may need multiple facilitators or coaches to ensure everyone can participate.
Requires preparation and coordination ahead of time to facilitate a productive workshop. a. Room needs to be set up. b. Outline or the training needs to be created. c. Supplemental materials may to be created. d. Good WIFI may be required.
Can be simple and lightweight (e.g. bring your laptop and learn: how to use git, how to make an MR, how to contribute to GitLab, etc. This is content that already exists in the handbook/website, but it can be very helpful to have someone walk you through it in person.)
The following are measures of a successful workshop.
Equipping: People learn a new skill or improve an existing skill.
Participation: Everyone has the opportunity to participate.
Presentations are one-way, one-to-many communication mode (one person speaking many people listening.)
One-way, one-to-many communication is easy to do remote while UGC-style, many-to-many discussion is harder to do remote.
If a GitLabber has an idea for a presentation they should do this outside of the Summit (e.g. schedule a remote call, livestream or upload the recording to YouTube, link it in the training section of the handbook, etc.)
Customers and Users presentations are good for the Summit so that more GitLabbers can hear from our customers and experience greater customer empathy.
The following are measures of a successful presentation.
TODO: Add results
Most UGCs can, and should, have diverse group of folks attending like GitLabbers from different teams, SOs, customers, etc. There should also be scheduled time for teams to have team-only UGCs to discuss their work, strategize, and problem solve.
Functional groups meet together (e.g. East Sales, Pipe-to-Spend, Site Reliability Engineering, etc.)
Cross-functional groups meet together (e.g. Plan, Create, Verify, etc.)
Customers meet together without any GitLabbers in the room to talk freely to each other.
During the summit we'll have a live stream that is interactive (viewers ask questions).
The live stream is a way to generate tangible hiring and marketing benefits, this will help to sustain the large discretionary expense of the summit.
There will be only one mobile camera crew and it will be easy to recognize.
With the mobile camera crew will be two GitLab team members, a moderator for the chat and a facilitator that will interact with other team members.
We want the viewers (our team members that couldn't make it, the wider community, friends and family) to feel like participants instead of an audience. From time to time the facilitator will seek interaction by talking with team members.
You can always decline to enter in a conversation with the facilitator, just like you can decline a conversation with another team member.
If you don't want to be approached by the facilitator under any circumstances you can ask for an identifier from the organization.
The facilitator will avoid taking to team members wearing the identifier, significant others, and children. Significant others that want to interact are very welcome to approach the facilitator themselves.
Team members wearing the identifier and significant others might be visible in the shot as passers-by's. The camera crew try to avoid children passers-by's. As said elsewhere on this page we strongly discourage children from attending.