We're a distributed, all-remote company where people work remotely without missing out. For this, we use asynchronous communication and are as open as we can be by communicating through public issues, chat channels, and placing an emphasis on ensuring that conclusions of offline conversations are written down. These communication guidelines are meant to facilitate smooth communication in an ever-growing, all-remote company.
Always create an issue for things you work on. If it is worth spending time on, it is worth creating an issue since that enables other people to learn and help. You can always edit the description or close it when the problem changed to something different or was solved.
If a user suggests an enhancement, try and find an existing issue that addresses their concern, or create a new one. Ask if they'd like to elaborate on their idea in one of these issues.
Double link issues with related conversations. E.g. if there’s a ZenDesk ticket that causes you to open a GitLab.com issue, make sure to document the issue link in the ZenDesk ticket and vice versa. And when closing the issue, include reason or response from ZenDesk. Another example is to add "Report: " lines to the issue description with links to relevant issues and feature requests. When done add a comment to relevant issues (and close them if you are responsible for reporting back, or re-assign if you are not). This prevents internal confusion and us failing to report back to the reporters.
If two issues are related, crosslink them (a link from each issue to the other one). Put the link at the top of each issue's description with a short mention of the relationship (Report, etc.). If there are more than 2 issues, use one issue as the central one and crosslink all issues to this one. Please, also crosslink between ZenDesk and GitLab issues.
After a discussion about a feature update the issue description with the consensus or final conclusions. This makes it much easier to see the current state of an issue for everyone involved in the implementation and prevents confusion and discussion later on.
Submit the smallest item of work that makes sense. When creating an issue describe the smallest fix possible, put suggestions for enhancements in separate issues and link them. If you're new to GitLab and are writing documentation or instructions, submit your first merge request for at most 20 lines.
Do not leave issues open for a long time, issues should be actionable and realistic. If you are assigned to an issue but don't have time to work on it, assign it to someone else.
Make a conscious effort to prioritize your work. The priority of items depends on multiple factors: Is someone waiting for the answer? What is the impact if you delay it? How many people does it affect, etc.? This is detailed in Engineering Workflow.
We try not to assign issues to people but to have people pick issues in a milestone themselves.
Assign an issue to yourself as soon as you start to work on it, but not before that time. If you complete part of an issue and need someone else to take the next step, re-assign the issue to that person.
When re-assigning an issue, make sure that the issue description contains the latest information. The issue description should be the single source of truth.
When working on an issue, ask for feedback from your peers. For example, if you're a designer and you propose a design, ping a fellow designer to review your work. If they approve, you can move it to the next step. If they suggest changes, you get the opportunity to improve your design. This promotes collaboration and advances everyone's skills.
We keep our promises and do not make external promises without internal agreement.
To use email instead of chat it is OK to send an internal email that contains only a short message, similar as you would use in chat. Save time by not including a salutation like 'Hi Emma,' and first write the subject of the email which you copy and paste into the body. You are not expected to be available all the time. It is perfectly fine not to respond to emails and chat mentions until your planned work hours.
Sometimes synchronous communication is the better option, but do not default to it. For example, a video call can clear things up quickly when you are blocked. See the guidelines on video chats for more detail.
It is very OK to ask as many questions as you have, but ask them so many people can answer them and many people see the answer (so use issues or public chat channels instead of private messages or one-on-one emails) and make sure you document the answers.
If you mention something (a merge request, issue, commit, webpage, comment, etc.) please include a link to it.
All company data should be shareable by default. Don't use a local text file but rather leave comments on an issue.
When someone asks something give back a deadline or that you did it. Answers like: 'will do', 'OK', 'it is on my todo list' are not helpful. If it is small is better to spend 2 minutes and do the tasks so the other person can mentally forget about it. If it is large you need to figure out when you'll do it, by returning that information the other person might decide to solve it in another way if it takes too long.
It is OK to bring an issue to someone's attention with a CC ("cc @user"), but CCs alone are not enough if specific action is needed from someone. The mentioned user may read the issue and take no further action. If you need something, please explicitly communicate your need along with @ mentioning who you need it from.
Send one email per subject as multiple items in one email will cause delays (have to respond to everything) or misses (forgot one of the items).
Always reply to emails by replying to all, even when no action is needed. This lets the other person know that you received it. A thread is done when there is a single word reply, such as OK, thanks, or done.
If you forward an email without other comments please add FYI (for your information), FYA (for your action), or FYJ (for your judgment). If you forward an external request with FYJ it just means the person who forwarded it will not follow up on the request and expects you to decide if you should follow up or not.
Email forwarding rules are specified in the shared Email, Slack, and GitLab Groups and Aliases Google Doc accessible only to people in the company. If you want to be added or removed from an internal alias (for example, "firstname.lastname@example.org"), change a rule, or add a forwarding email alias, please suggest an edit in the doc.
Emails are asynchronous, for example, if your manager emails you on a weekend it is fine to reply during the workweek.
If an email is or has become urgent feel free to ping people via chat referencing the subject of the email.
If you use chat, please use a public channel and mention the person or group you want to reach. This ensures it is easy for other people to chime in, involve other people if needed, and learn from whatever is discussed.
If you use chat and plan to message 3 or more people, we recommend to create a chat channel for customer/issue/project/problem/partnership.
If you're only referring to someone, but don't actually need their attention, and want to spare them from getting notified, spell out their name normally without @ mentioning them.
If the subject is of value to the wider community, consider commenting on an existing issue or opening a new issue instead.
Despite the instantaneous nature of chat, it should be considered asynchronous communication. Don't expect an instantaneous response; you have no idea what the other person is doing.
If you must send a private message, don't start a conversation with "Hi" or "Hey" as that interrupts their work without communicating anything. If you have a quick question, just ask the question directly and the person will respond asynchronously. If you truly need to have a synchronous communication, then start by asking for that explicitly, while mentioning the subject. e.g. "I'm having trouble understanding issue #x, can we talk about it quickly?".
Unless you're in an active chat, don't break up a topic into multiple messages as each one will result in a notification which can be disruptive. Use threads if you want to provide extra info to the question/comment you posted. Especially in channels like #questions are threads very valuable to keep conversations about a certain question together.
Because we work globally, you may receive chat mentions at any time of day. Please consider enabling Slack's Do not disturb functionality so you don't get interrupted, for example, in your evenings.
Do not feel obligated to respond to chat messages when you are not working.
Feel free to send a colleague a link to these guidelines if the communication in Slack should be done asynchronously.
If you are having a hard time keeping up with chat messages, you can update your preferences to have Slack email you all notifications. To change the setting, go to Preferences > Notifications > When I'm not active on desktop... and "send me email notifications".
Please avoid using @here unless this is about something urgent and important. In chat try to keep the use of keywords that mention the whole channel to a minimum. They should only be used for pings that are both urgent and important, not just important. By overusing channel mentions you make it harder to respond to personal mentions in a timely manner since people get pinged too frequently. If something is urgent and important:
Use @here to notify all currently active members in the room. Please only us @here if the message is important and urgent.
Use @channel to notify ALL members in the room, irrespective of away status.
If something is important but not urgent - like complimenting or encouraging the entire team - use email or post in the channel without @-mentioning the team.
If you agree in a chat to start a video call (typically by asking "Call?") the person that didn't leave the last comment starts the call. So either respond to the "Call?" request with a video link or say "Yes" and let the other person start it. Don't say "Yes" and start a call 5 seconds later since it is likely you'll both be creating a video call link at the same time.
The usage of ChatBots for integrations can sometimes depend upon the name of the chat room. You should consult the room about such integrations before changing the name of commonly used / popular rooms in order to avoid inadvertently breaking integrations.
If you are aware that your teammate is on vacation, avoid mentioning them in a high volume channel. It will be difficult to find the information or question when they return. If you need to ensure they refer back to the thread, ensure to send them a link to the relevant Slack message through a direct message.
It's not rude to leave a channel. When you're no longer interested in the conversations happening in a channel, feel free to leave it so it won't distract you anymore.
Never use a Google Doc / Presentations for something non-confidential that has to end up on the website or the handbook. Work on these edits via commits to a merge request. Then link to the merge request or diff to present the change to people. This prevents a duplication of effort and/or an out of date handbook.
If you do need a Google Doc, create one with your company G Suite (formerly Google Apps) account. By default, share it with the whole company using the Anyone at GitLab can find and access link sharing permission and the Anyone within GitLab can edit access permission (preferred) or the Anyone within GitLab can comment access permission. Easily do this by creating Google Docs within a Shared Folder in Google Drive.
When referring to a Google Doc or folder on the Google Drive in the handbook, refrain from directly linking it. Instead, indicate the name of the doc. If you link the url people from outside the organization can request access, creating workload and the potential for mistakes. (In the past, linking a Google Doc has led to inadvertently opening the sharing settings beyond what was intended.) This also helps prevent spam from people outside GitLab requesting access to a doc when clicking its link.
If you are having trouble finding a shared Google Doc, make sure you Search <your domain> in Google Drive.
In our handbook, if you find yourself wondering whether it is better to provide a public link to a Google Doc vs. writing out the content on the website, use the following guideline: Is this document frequently adapted / customized? If yes, then provide a link, making sure that the document can be commented on by anyone with the link. For instance, this is how we share our employment contracts. If the document is rarely customized, then provide the content directly on the site and deprecate the Google Doc.
If you want to quickly find where a team member's cursor is in a Google Doc, click their icon at the top of the document and the app will jump you to the current location. This works in Sheets and Presentations as well.
How to deprecate a Google doc
Add 'Deprecated: ' to the start of the title.
Remove the content you moved.
Add a link to the the new location at the begining of the doc/first slide/first tab
Add a link to the merge request or commit that moved it (if applicable)
All presentations are made in Google Slides using our template named 'GitLab-Deck-Template-Light'.
The title of every slide should be the message you want the audience to take away, not the subject matter. So use 'Our revenue more than doubled' instead of 'Revenue growth'.
Thank people that did a great job in our "Thanks" chat channel. If someone is a team member just @ mention them. If multiple people were working on something try mentioning each person by "@name". "Thanks everyone" does not say much.
To thank someone who is not a team member, mention your manager, our People Ops Coordinator, the name of the person, a quirky gift and link to their work. For example, "@manager, @peopleopscoordinator: Joe deserves a lawnmower for link". With your manager's blessing, the People Ops Coordinator will approach the person in question for their address saying we want to send some swag. We'll ship it in gift wrap with "Thanks for your great work on link, love from @gitlab".
Don't thank the CEO or other executives for something that the company paid for, thank GitLab instead.
Not sure where to go?
If there is something that you want to discuss, but you do not feel that it is a reasonable option to discuss with either your manager or CEO, then you can reach out to any of the other C-level GitLabbers or our board member Bruce Armstrong.
Everyone at GitLab is invited to the company call.
We also have a company call for GitLabbers in the APAC region. This call will also be recorded so the rest of the company can see what their colleagues have been up to! Everyone is encouraged to join this call as well, but it is not mandatory.
Every last Friday of the month we have an AMA to talk about anything the people at our company are thinking about.
We use Zoom for the call since Google Hangouts is capped at 15 people (please be sure to mute your microphone). If using the Zoom web app, you can go to settings and check always mute microphone when joining a meeting.
The link is in the calendar invite and also listed at the top of the company call agenda Google Doc called Company Call Agenda.
The call is recorded automatically, and all calls are transferred every hour to a Google Drive folder called "GitLab Videos". There is a subfolder called "GitLab Company Call", which is accessible to all users with a GitLab.com e-mail account.
We start on time and do not wait for people.
The person who has the first item on the agenda starts the call.
If you are unable to attend just add your name to the company call agenda as "Not attending".
We start by discussing the subjects that are on the agenda for today.
Everyone is free to add subjects. Please start with your name and be sure to link to an issue, merge request, or commit if it is relevant.
When done with a point mention the subject of the next item and hand over to the next person.
When someone passes the call to you, no need to say, “Can you hear me?” Just begin talking. If we can’t hear you, we’ll let you know.
After the general announcements, attendees share their personal interests by adding their name to the schedule or by discussing in a mixer call. The schedule is as follows:
Monday: Any topic
Tuesday: Mixer Calls, where we split off into smaller groups to discuss what we have been up to. No need to add yourself to the agenda on this day.
Wednesday: Any Topic
Thursday: Mixer Calls, where we split off into smaller groups to discuss what we have been up to. No need to add yourself to the agenda on this day.
Friday: Any topic
Please add your name to the agenda at least 15 minutes before the company call is scheduled to start. We encourage 15-20 people to share an update of about a minute to leave time for all listed on the agenda. If you see that a particular day is congested and you have already shared over the last 2 weeks, please consider moving your name to a later week.
It is OK to talk over people or interrupt people to ask questions, cheer for them or show your compassion. This encourages more conversation and feedback in the call. Also see the interruption item in video calls.
Please look if the person you hand over to is present in the participant list so you don't hand over to someone who is not present.
The last person wishes everyone a good day.
Even if you cannot join the call, consider reviewing the recorded call or at minimum read through the agenda and the links from there. We often use the company call to make announcements or discuss changes in processes, so make sure to catch up on the news if you have missed a company call (or more).
If you are scheduling a meeting, avoid scheduling during the company call so that meeting attendees do not need to choose between your meeting and the company call. As a remote workforce, the company call is an important part of our culture.
We split into small groups of around eight on the Thursday Company Call, using Zoom's Breakout Rooms feature. The groups are randomly assigned based on the participants in the Company Call.
These calls are unstructured to allow for natural interaction, but everyone should get a chance to share at least once.
It helps to pause slightly between talking about different topics to allow for discussion.
If you are unsure of who should start or speak next, follow the order listed in Zoom.
Prompts for things you might share:
Hobbies and interests
What you've been up to recently
Things you're looking forward to
Sports and wellness
Cooking, Entertaining, and Creative Projects
Travel, Kids, Family, and Pets
Music, books, TV & Movies, video/board games
Setting up a Mixer Call
The calls take place using the People Ops zoom account, which has Breakout Rooms enabled.
After the announcements, the host will start the Breakout Rooms from the Zoom interface, choosing a number of rooms that averages 8-9 people per room.
Anyone who joins late or accidentally leaves their Breakout can be manually assigned to a room.
Release Retrospectives and Kickoffs
After GitLab releases a new version on the 22nd of each month, we have a 30-minute call a few days later reflecting on what could have been better:
What went well this month?
What went wrong this month?
What could we have done better?
We spend the first part of the retrospective meeting reviewing the action items from the previous month.
On the 8th of each month (or the next business day), we have a kickoff meeting for the version that will be released in the following month. The product team and other leads will have already had discussions on what should be prioritized for that release. The purpose of this kickoff is to get everyone on the same page and to invite comments.
The #random chat channel is your go-to place to share random ideas, pictures, articles, and more. It's a great channel to check out when you need a mental break.
Come hang out any time in the random room, an open Google Hangout video chat where anyone with a GitLab email address can come and leave as they please. The link is in the description of the #random chat channel; consider bookmarking it. This room is open for all and should be distinct from the Coffee Break Calls, which are 1x1 conversations between teammates.
If you want to ask GitLabbers if they are available for an event please send a calendar invite with Google Calendar with your Google GitLab account to their Google GitLab account. This makes it easier for people to check availability and to put on their calendar. It automatically shows up on calendars even when the email is not opened. It is easier to signal presence and to see the status of everyone. Please respond quickly to invites so people can make plans.
Every scheduled meeting should either have a Google Presentation (for example for functional updates that don't require participation) or a Google Doc (for most meetings) linked. If it is a Google Doc it should have an agenda, including any preparation materials (can be a presentation). Put the agenda in a Google Doc that has edits rights for all participants (including people not part of GitLab Inc.). Link the Google Doc from the meeting invite. Take notes of the points and todos during the meeting. Nobody wants to write up a meeting after the fact and this helps to structure the thought process and everyone can contribute. Being able to structure conclusions and follow up actions in realtime makes a video call more effective than an in-person meeting. If it is important enough to schedule a meeting it is important enough to have a Doc linked. If we want to be on the same page we should be looking at that page.
If you want to check if a team member is available for an outside meeting, create a calendar appointment and invite the team member only after they respond yes. Then invite outside people.
When scheduling a call with multiple people, invite them using a Google Calendar that is your own, or one specific to the people joining, so the calendar item doesn't unnecessarily appear on other people's calendars.
If you want to move a meeting just move the calendar appointment instead of reaching out via other channels. Note the change at the top of the description.
Please click 'Guests can modify event' so people can update the time in the calendar instead of having to reach out via other channels. You can configure this to be checked by default under Event Settings.)
When scheduling a meeting we value people's time and prefer the "speedy meetings" setting in our Google Calendar. This gives us meetings of, for example, 25 or 50 minutes leaving some time to write notes etc before continuing to our next call or meeting. (This setting can be found under the calendar Settings menu at "default event duration")
When creating a calendar event that will be used company wide, please place it on the GitLab Availability Calendar. That way the event is easily located by all individuals.
When you need to cancel a meeting, make sure to delete/decline the meeting and choose the option Delete & update guests to make sure everyone knows you can't attend and don't wait for you.
If you want to schedule a meeting with a person not on the team please use Calendly. Use Google Calendar directly if scheduling with a GitLabber.
Indicate your availability in Google Calendar. This is important to facilitate scheduling, since we work in different timezones and have different holidays.
Put your planned away time including holidays, vacation, travel time, and other leave in both the GitLab Availability Calendar and your own calendar.
Set your working hours in your Google Calendar settings.
Use video calls if you find yourself going back and forth in an issue/via email or over chat. Rule of thumb: if you have gone back and forth 3 times, it's time for a video call.
Having pets, children, significant others, friends, and family visible during video chats is encouraged. If they are human, ask them to wave at your remote team member to say "Hi".
For meetings that are scheduled via calendar there is automatically a Google Hangouts URL added. This is the meeting place. Having a url in advance is much more reliable than trying to call via Hangouts as the meeting start.
Google Calendar also has a Zoom plugin where you can easily add a Zoom link for a video call to the invite
For meetings that are scheduled with Zoom:
Make sure to take out the Google Hangouts link to avoid confusion.
If you need more privileges on Zoom (longer meeting times, more people in the meeting, etc.), please contact People Ops as described specifically for Zoom.
Note that if you select to record meetings to the cloud (setting within Zoom), they will be automatically placed in the GitLab Videos folder in Google Drive on an hourly basis. You can find these videos in Google Drive by entering in the search bar: title:"GitLab Videos" source:domain.
Note also that after a meeting ends, Zoom may take some time to process the recording before it is actually available. The sync to Google Drive happens on the hour mark, so if the recording is not available, it may take another hour to be transferred.
If you are sharing your screen, chat is hidden by default, but you can get it back by clicking on the ... menu and selecting Chat.
Use a headset with a microphone, Apple Earpods are great. Do not use computer speakers, they cause an echo. Do not use your computer microphone, it accentuates background noise. If you want to use your Bose headphones that is fine but please ensure the microphone is active.
Consider using a utility to easily mute/unmute yourself, see Shush in the tools section.
In video calls everyone should own a camera and a headset, even when they are in the same room. This helps seeing and hearing the person that is talking. It also allows people to easily talk and mute themselves. Using a headset also prevents echo. You wouldn't share an office seat together, so don't share your virtual seat at the table.
Please speak up asap when someone on the call hasn't muted their mic to avoid disturbances to the person speaking
We start on time and do not wait for people. People are expected to join no later than the scheduled minute of the meeting (before :01 if it is scheduled for :00). The question 'is everyone here' is not needed.
It feels rude in video calls to interrupt people. This is because the latency causes you to talk over the speaker for longer than during an in-person meeting. We should not be discouraged by this, the questions and context provided by interruptions are valuable. This is a situation where we have to do something counter-intuitive to make all-remote meetings work. In GitLab everyone is encouraged to interrupt the speaker in a video call to ask a question or offer context. We want everyone to contribute instead of a monologue. Just like in-person meetings be cognizant of when, who, and how you interrupt, we don't want manterrupting.
We end on the scheduled time. It might feel rude to end a meeting, but you're actually allowing all attendees to be on time for their next meeting.
We recommend you set your Google calendar access permissions to 'Make available for GitLab - See all event details'. Consider marking the following appointments as 'Private':
Confidential & sensitive meetings with third-parties outside of GitLab
1-1 performance or evaluation meetings
Meetings on organizational changes
There are several benefits and reasons to sharing your calendar with everyone at GitLab:
Transparency is one of our values and sharing what you work on is in line with our message of "be open about as many things as possible".
Due to our timezone differences, there are small windows of time where our availabilities overlap. If other members need to schedule a new meeting, seeing the details of recurring meetings (such as 1-1s) will allow for more flexibility in scheduling without needing to wait for a confirmation from the team member. This speaks to our value to be more efficient.
User Communication Guidelines
Keep conversations positive, friendly, real, and productive while adding value.
If you make a mistake, admit it. Be upfront and be quick with your correction. If you're posting to a blog, you may choose to modify an earlier post. Just make it clear that you have done so.
There can be a fine line between healthy debate and incendiary reaction. Try to frame what you write to invite differing points of view without inflaming others. You don’t need to respond to every criticism or barb. Be careful and considerate.
Answer questions, thank people even if it’s just a few words. Make it a two way conversation.
We use Unix style (lf) line endings, not Windows style (crlf), please ensure *.md text eol=lf is set in the repository's .gitattributes and run git config --global core.autocrlf input on your client.
Do not create links like "here" or "click here". All links should have relevant anchor text that describes what they link to, such as: "GitLab CI source installation documentation". Using meaningful links is important to both search engine crawlers (SEO) and people with accessibility issues.
Always use ISO dates in all writing and legal documents since other formats lead to online confusion. Use yyyy-mm-dd, for example 2015-04-13, and never 04-13-2015, 13-04-2015, 2015/04/13, nor March 4, 2013. Even if you use a unambiguous alternative format it is still harder to search for a date, sort on a date, and for other team members to know we use the iso standard. For quarters use 2018-Q3.
Remember that not everyone is working in the same timezone; what may be morning for you is evening for someone else. Try to say 3 hours ago or 4 hours from now, or use a timestamp, including a timezone reference.
For engineering (for example production postmortems) we use UTC as the timezone. For all other uses we use Pacific time since we are a San Francisco based company. Please refer to time as '9:00 Pacific' and not PST since that is ambiguous during daylight savings.
If you have multiple points in a comment or email, please number them to make replies easier.
When you reference an issue, merge request, comment, commit, page, doc, etc. and you have the URL available please paste that in.
In making URLs, always prefer hyphens to underscores, and always use lowercase.
The community includes users, contributors, core team members, customers, people working for GitLab Inc., and friends of GitLab. If you want to refer to "people not working for GitLab Inc." just say that and don't use the word community. If you want to refer to people working for GitLab Inc. you can also use "the GitLab Inc. team" but don't use the "GitLab Inc. employees".
When we refer to the GitLab community excluding GitLabbers please say "wider community" instead of "community".
All people working for GitLab (the company) are the GitLab team. We also have the Core team that consists of volunteers.
Please always refer to GitLab Inc. people as GitLabbers, not employees.
Mandel Communications refers to SCIPAB at the "surefire, six-step method for starting any conversation or presentation." When you only have a few minutes to present your case or grab your listeners attention, this six-step process can help you communicate better and faster.
Situation - Expresses the current state for discussion
Complication - Summarzies the critical issues, challenges or opportunities
Implication - Provides insight into the consequences that will be a result of if the Complications are not addressed.
Position - Notes the presenter's opinion on the necessary changes which should be made.
Action - Defines the expectations of the target audience/listeners.
Benefit - Clearly concludes how the Position and Action sections will address the Complications. This method can be used in presentations, emails and everyday conversations. Example - The Management team asking for time to resolve a problem
S - The failure rate last year for product X1 was an acceptable 1.5%.
C - Because of supply shortages in the current fiscal year we are forced to change the material of a key component.
I - Unfortunately, that resulted in the failure rate doubling this year.
P - It is critical we address this problem immediately.
A - Please approve the team 5 days to investigate the specific causes of the increase and establish the necessary next steps.
B - By doing this we will redue the failure rate to an acceptabel level and develop guidelines for preventing such problems in the future. More information can be found at SCIPAB- Six Steps To Reach Your Audience
Beamy is our company conference call robot. It lives in the San Francisco boardroom. Its main purpose is to allow those outside of the boardroom a view into the space and people. When you call in to the beam your face will appear on the screen (so make sure your webcam works) and you can drive the robot around the boardroom. It simulates being in the space without physically being there. It is really cool and everyone should try it and have fun with it.
You should have received an invite during onboarding to connect and to download a desktop client. If you did not receive the invite, please request one in the Slack #peopleops channel.
Beamy times: 8am until 6pm Pacific time. Please check the current time! on workdays and during all company events, for other times please @mention Sytse in the Slack #valley channel to see if it is OK. It is on auto connect so you'll beam right in.
The email invite will come from "Suitable Tech". Once you are sent an invite you can beam in at any time and drive around our beam. Don’t forget to park it back on the charger when you are done. You can do so by driving up to the charger, when you see a green outline press AND HOLD 'p' until it's parked. Make sure it is charging, otherwise try again.
If you don't use headphones be careful about your volume and microphone placement, it might start singing, if so immediately mute your microphone and switch to headphones.
If a phone number is required, leave this field empty by default. If that is not possible, then use the general number (+1-415-761-1791), but be aware that this number simply guides to a voice message that refers the caller back to contacting us via email.
Organization code names
Listed in Google Sheet under 'Organization code names'
To make it easier to recognize code names we base them on classic car models.
There are two types of code names:
Don't mention publicly We can use code names anywhere we regularly share items in that medium with people outside the company: issue trackers, functional group updates, etc. For these we don't have to use code names in things that are never published: salesforce, zuora, zendesk, verbal conversations.
Don't write down there are organizations that we shouldn't write down anywhere.
At GitLab we use ubiquitous language to increase communication efficiency. This is defined in Domain-driven design as: "A language structured around the domain model and used by all team members to connect all the activities of the team with the software.". We use it for activities in GitLab, even ones not implemented in software. By having ubiquitous words to identify concepts we prevent confusion over what is meant, for example we refer to parts of our organization as a function, department, or group depending on exactly what is meant. Make sure that domains don't overlap, for example organization size and deal size don't reuse words to prevent overlap. If a term is ambiguous don't use it, for example our hiring definitons have roles and vacancies but avoid the ambiguous word job. Make sure that people can infer as much as possible from the word, for example our subscription options allow you to know if someone if using self-managed or GitLab.com. Make sure terms don't overlap without clearly defining how and why, for example see our tier definitions. Keep terms to one or at most two words to prevent people from introducing ambiguity by shortening a term. When using two words make the first word unique people because tend to drop the second word more often.
If you are hosting a meeting that would be interesting, please livestream using Google Hangouts.
Notify participants the meeting is being livestreamed before, and at the start of, the meeting.
Login to YouTube and click on the Tanuki in the upper right corner. Choose "Creator Studio" (read the secure note in 1Password called "YouTube" for instructions on how to get access).
Choose "Live Streaming", then "Events" from the left side menu, and click on "New live event" in the upper right corner.
Give your event a title, description, and keep the privavy dropdown on the default Public setting.
Set the time of the livestream, and set the "Type" to 'Quick'. If you want to go live immediately, keep the default Now setting and choose "Go live now". This will place you in a Google Hangout but will not automatically begin the livestream.
To schedule the live event for later, choose the day and time from the drop downs, and click "Create event" to save.
To start your scheduled live stream event, navigate to the "Events" page in YouTube, find your event, and choose "Start Hangout On Air". This will plae you in a Google Hangout but will not automatically begin the livestream.
Up to 50 participants can join the Google Hangout. To invite participants, click on the Invite People icon from menu in the top center of screen. You can either share the permanent link, or invite individuals.
Once capacity is met, anyone else can participate via the YouTube Watch page.
When you are ready to broadcast, choose the green "Start Broadcast button" at the bottom of the Google Hangout console. You will see a "LIVE" message once streaming.
Log in to the Zoom account of the meeting and go to the menu on the right and choose "My Recordings" (it can take up to 30 minutes before the recording is available to be shared).
Select the meeting and download the recording to your computer (if you can't find the recording because it was a while ago check "Trash" in the menu on the top left and "Recover" the recording).
Go to the YouTube upload page and log in to the GitLab account (read the secure note in 1Password called "YouTube" for instructions on how to get access).
Drag and drop your recording into the window to upload it. Keep the privacy dropdown on the default 'Public' setting (unless there is confidential material).
While it's uploading, edit the title and description. Place "Confidential:" at the beginning of the video's title if the video will be kept unlisted on our YouTube channel.
Be sure to include relevant links (for example a handbook page or presentation) in the description, and add the video to any relevant playlists.
When it is done uploading, press publish, then click on the Embed tab and copy the code, and insert that in the relevant part of the handbook or documentation.
Don't worry about the quality
There is no minimum quality, so please share it on our GitLab Youtube channel, as long as there is nothing inappropriate or confidential.
Everyone at the company probably has at least one conversation every week that is relevant to more people, so please share it.
We always list videos publicly instead of having them unlisted, unless there is confidential material. This allows more people to find the content.
Don't worry about whether or not it will be interesting to absolutely everyone. Just give it a descriptive title so people know what it is about, and let them decide whether or not they should watch it.
Make sure that all participants are aware that you're recording.
You don't have to be sure it is interesting and OK to share when you start recording; you can make that decision after the fact.
If you record an in-person conversation with your mobile phone please hold your phone in landscape (horizontal) mode.
Allows more people to participate in real-time.
The recording is automatically uploaded to YouTube.
Allows more people to benefit from the content.
Allows the original participants to review the content later.
You can link to it instead of repeating yourself.
Why Youtube and not Google Drive?
Always use YouTube and never use Google Drive, because YouTube videos: