We value results, transparency, sharing, freedom, efficiency, frugality, collaboration, directness, kindness, diversity, boring solutions, and quirkiness:
- Results: We care about what you achieve; the code you shipped, the user you made happy, and the team member you helped. Do not compete by proclaiming how many hours you worked yesterday because we don't want someone who took the afternoon off to feel like they did something wrong. Instead celebrate the achievements of yourself and your teammates. We want people to have the desire to ship.
- Transparency: Be open about as many things as possible. By making information public we can reduce the threshold to contribution and make collaboration easier. An example is the public repository of this website that also contains this company handbook. Everything we do is public by default, for example the GitLab CE and GitLab EE issue trackers, but also marketing and infrastructure. Transparency creates awareness for GitLab, allows us to recruit people that care about our culture, it gets us more and faster feedback from people outside the company, and makes it easier collaborate with them. There are exceptions, material that is not public by default is documented in the general guidelines. On a personal level you should tell it like it is instead of putting up a poker face. Don't be afraid to admit you made a mistake or were wrong. When something went wrong it is a great opportunity to say 'what’s the kaizenmoment here' and find a better way without hurt feelings.
- Sharing: We care about giving great software, documentation, examples, lessons, and processes to the world. An example is the MIT licensed GitLab CE. We believe that open source creates more value than it captures. We are grateful to our customers, users, partners, investors, and the open source ecosystem.
- Freedom: You should have clear objectives and the freedom to work on them as you see fit. Any instructions are open to discussion. You don't have to defend how you spend your day. We trust team members to do the right thing instead of having rigid rules.
- Efficiency: We care about working on the right things, not doing more than needed, and not duplicating work. This enables us to achieve more progress with less people and makes our work more fulfilling. We think of how we can make the company better instead of being territorial or defensive.
- Frugality: Amazon states it best with: "Accomplish more with less. Constraints breed resourcefulness, self-sufficiency and invention. There are no extra points for growing headcount, budget size or fixed expense."
- Collaboration: Helping others is a priority. You are expected to ask others for help and advise. Anyone can chime in on any subject. You don't have to comply with all feedback but you should always take it seriously. An example is the inclusion of people from outside GitLab Inc. in the core team.
- Directness: We try to channel our inner Ben Horowitz by being both straightforward and kind, an uncommon cocktail of no-bullshit and no-asshole.
- Kindness: We don't want jerks in our team. Some companies say Evaluate People Accurately, Not "Kindly". We're all for accurate assessment but we think it must be done in a kind way. Give as much positive feedback as you can and do it in a public way. Give negative feedback in the smallest setting possible, one-on-one video calls are preferred. Clearly make negative feedback about the work itself, not the person. When giving feedback always provide at least one clear and recent example. If a person is going through a hard time in their personal life, then take that into account. An example of giving positive feedback is our thanks chat channel.
- Diversity: The community consists of people from all over the world, with different backgrounds and opinions. We hire globally and encourage hiring in a diverse set of countries. We work to make everyone feel welcome and to increase the participation of underrepresented minorities and nationalities in our community and company. An example is our sponsorship of diversity events.
- Boring solutions: Use the most simple and boring solution for a problem. You can always make it more complex later if that is needed. The speed of innovation for our organization and product is constrained by the total complexity we added so far, so every little reduction in complexity helps. Don't pick an interesting technology just to make your work more fun, using code that is popular will ensure many bugs are already solved and its familiarity makes it easier for others to contribute.
- Quirkiness: Unexpected and unconventional things make life more interesting. Celebrate and encourage quirky gifts, habits, behavior, and points of view. An example is our team call where we spend most of our time talking about what we did in our private lives, from fire-throwing to knitting. Open source is a great way to interact with interesting people. We try to hire people who think work is a great way to express themselves.
- Working at GitLab Inc. is cooperating with the most talented people you've ever worked with, being themost productive you'll ever be, and creating software that is helping the most people you've ever reached.
- We recognize that inspiration is perishable, so if you’re enthusiastic about something that generates great results in relatively little time feel free to work on that.
- Do what is right for our customers and the rest of the GitLab community, do what is best over the long term, don't be evil.
- We create simple software to accomplish complex collaborative tasks.
- We use our own software to accomplish complex collaborative tasks.
- Do not make jokes or unfriendly remarks about race, ethnic origin, skin color, gender or sexual orientation.
- Use inclusive language. For example, prefer 'Hi everybody' or 'Hi people' to 'Hi guys'.
- Share problems you run into, ask for help, be forthcoming with information and speak up.
- All our procedures and templates are stored in (mostly public) git repositories instead of Google/Word documents. This makes them easier to find and suggest changes to with the organization and shows our commitment to open collaboration outside the organization.
- Work out in the open, try to use public issue trackers and repositories when possible.
- Most things are public unless there is a reason not to, not public by default are: financial information, legal, job applications/compensation/feedback and partnerships with other companies.
- Share solutions you find and answers you receive with the whole community.
- If you make a mistake, don't worry, correct it and proactively let the affected party, your team, and the CEO know what happened, how you corrected it and how, if needed, you changed the process to prevent future mistakes.
- You can always refuse to deal with people that treat you badly and get out of situations that make you feel uncomfortable.
- Everyone can remind anyone in the company about these guidelines. If there is a disagreement about the interpretations, the discussion can be escalated to more people within the company without repercussions.
- If you are unhappy with anything (your duties, your colleague, your boss, your salary, your location, your computer) please let your boss, or the CEO, know as soon as you realize it. We want to solve problems while they are small.
- We want to have a great company so if you meet people that are better than yourself try to recruit them to join the company.
- Make a conscious effort to recognize the constraints of others within the team. For example, sales is hard because you are dependent on another organization, and Development is hard because you have to preserve the ability to quickly improve the product in the future.
- Our strategy is detailed on the Strategy page, please read it and contribute.
- For each action or comment, it helps to ask yourself (i) does this help the company achieve its strategic goals? (ii) is this in the company's interest, and finally, (iii) how can I contribute to this effort/issue in a constructive way?
- There is no need for consensus, make sure that you give people that might have good insights a chance to respond (by /cc'ing them) but make a call yourself because consensus doesn't scale.
- Everyone at the company cares about your output. Being away from the keyboard during the workday, doing private browsing or making personal phone calls is fine and encouraged.
- If you fix something for GitLab.com or one of our users make sure to make that the default (preferred) and radiate the information in the docs. We should run GitLab.com with the default settings and setup our users would also have.
- Everything is always in draft and subject to change, including this handbook. So do not delay documenting things and do not include draft in the titles of documents. Ensure everyone can read the current state, nothing will ever be finished.
- Explicitly note what next action you propose or expect and from whom.
- When you reply to a request please do so after you have completed the request or indicate when you plan to do it. In the latter case always send a second message when the request is complete.
- Respect the privacy of our users and your fellow team members. Secure our production data at all times. Only work with production data when this is needed to perform your job. Looking into production data for malicious reasons (for example LOVEINT or spying on direct messages of team members) is a fireable offense.
- Most guidelines in this handbook are meant to help and unless they state otherwise it is meant to help more than being an absolute rule. Don't be afraid to do something because you can't oversee all guidelines. Be gentle when reminding people about these guidelines, for example say: "It is not a problem, but next time please consider the following guideline from the handbook".
Documenting things in the handbook takes more time initially and it requires thinking. But it saves time over a longer period and it is essential to scale and adapt our organization. It is not unlike writing tests for your software. Please follow these guidelines and remind others of them.
- If you need to discuss with a team member for help please realize that probably the majority of the community also doesn't know, be sure to document the answer to radiate this information to the whole community. After the question is answered discuss where it should be documented and who will do it. You can remind other people of this by asking 'who will document this'?
- When you discuss something in chat always try to link to a URL where relevant, for example the documentation you have a question about or the page that answered your question. You can remind other people of this by asking 'can you please link'?
- To change a guideline or process, suggest an edit in the form of a merge request. After it is merged you can talk about it during the team call if applicable. You can remind other people of this by asking 'can you please send an MR for the handbook'?
- Communicate process changes by linking to the diff (a commit that shows the changes before and after). Do not change the process first, and then view the documentation as a lower priority task. Planning to do the documentation later inevitably leads to duplicate work communicating the change and to outdated documentation. You can remind other people of this by asking 'can you please update the handbook first?'.
- When communicating something always include a link to the relevant (and up to date) part of thehandbook instead of including the text in the email/chat/etc. You can remind other people of this by asking 'can you please link to the relevant part of the handbook?'.
- If you copy content please remove it at the origin place and replace it with a link to the new content. Duplicate content leads to updating it in the wrong place, keep it DRY.
Many things can be documented in the handbook, but this will mostly be read by team members. If something can concern users of GitLab it should be documented in the GitLab documentation, the GitLab Development Kit (GDK), our CONTRIBUTING file or the PROCESS file.
We're a distributed, remote-only company where people work remote without missing out. For this, we useasynchronous 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 remote-only company. Please keep in mind that you represent GitLab and our culture, also on Social Media. When commenting on posts please keep in mind: "Don't argue but represent."
- All written communication happens in English, even when sent one on one, because sometimes you need to forward an email or chat.
- Use asynchronous communication when possible (issues and email instead of chat), issues are preferred over email, email is preferred over chat, announcements happen on the team call agenda, and people should be able to do their work without getting interrupted by chat.
- 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 try to 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 leave comments on an issue.
- When using email, 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, 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) or FYA (for your action). If you forward an external request with FYA it doesn't mean that the company should do whatever is proposed, it just means the person who forwarded it will not follow up on the request themselves and expects you to do so instead.
- Email forwarding rules are specified in the shared "GitLab Email Forwarding" Google doc accessible to people in the company, if you want to be added or removed from an internal alias (e.g.
firstname.lastname@example.org), change a rule, or add a forwarding email alias, please make a suggestion in the document.
- 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 whenever possible, mention the person you want to reach if it is urgent. This ensures it is easy for other people to chime in, and easy to involve other people, if needed.
- 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 as well as 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 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.
- Work on website edits via commits to a merge request. Never use a Google doc for something non-confidential that is intended for the website.
- If you do need a Google Doc, then create the doc with your company Google Apps account. By default share Google docs with the whole company 'anyone at GitLab can find and access' with edit (preferred) or comment access for everyone. An easy way to do this, is to create your Google docs in a Shared Folder in Google Drive.
- When referring to a Google Doc in the handbook, refrain from providing the direct link. Instead, write the name of the Google Doc. In the past, giving the URL of a doc has led to inadvertent opening of sharing settings beyond what was intended, and it also helps prevent spam from people outside of GitLab who request access to the doc when they see the 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.
- Use video calls if you find yourself going back and forth in an issue/via email or over chat.
- 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'.
- 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 team members or our board member Bruce Armstrong.
- Always create an issue for things you work on. If it is worth spending time on, it is worth creating an issue for it since that enables other people to learn and help. You can always edit the description or close it when the problem is something different or disappears.
- 'Double link' issues to prevent internal confusion and us failing to report back to the reporters. For example, open an issue with link to ZenDesk and close the issue with copy of the response. Or add 'Report: ' lines to the description with links to relevant issues and feature requests and ensure they are closed and note this with a comment. If you are not responsible for reporting back please do not close an issue, instead reassign it.
- If issues are related, crosslink them (a link from each issue to the other one). Put the links at the top of the issues' 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 body 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.
- Give the community the chance to help. For example: place issues on the feedback tracker, leave comments in rake check tests about what you can run manually and ask 'Can you send a merge request to fix this?'.
- 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 but don't have time, assign it to someone else. If nobody is assigned and it is not a priority, please ensure the community can help and close it.
- Make a conscious effort to prioritize your work. The priority of items depends on multiple factors: is there a team member waiting for the answer, what is the impact if you delay it, how many people does it affect, etc. This is detailed in the development workflow document.
- Use the public issue trackers on GitLab.com for everything since we work out in the open. We do still use some private issue trackers on our internal dev.gitlab.org server, such as for organizational issues that do not have a home in one of the public team trackers that can be found on the team structure page.
- Pick issues from the current milestone.
- 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 reassigning an issue, make sure that the issue body contains the latest information. The issue body should be the single source of truth.
- We keep our promises and do not make external promises without internal agreement.
- Even when something is not done, share it internally so people can comment early and prevent rework. Mark the merge request Work In Progress so it is not merged by accident.
- When you create a merge request, mention the issue(s) that it solves in the description. If any followup actions are required on the issue after the merge request is merged, like reporting back to any customers or writing documentation, avoid auto closing it by saying
- Once a merge request is created, make sure to assign it to the proper person:
- For example a merge request that fixes a frontend issue should have the
Frontendlabel and be assigned to a Frontend Engineer for review. For other workflow labels please see PROCESS.md.
- A merge request that is related to Continuous Integration should be assigned to the GitLab CI lead.
- All other merge requests should be assigned for review to either a merge request miniboss or endboss. You can find the people with these roles on the team page.
- Once a merge request has gone through review by a miniboss, they will assign it to an endboss who will do a final review and perform the actual merge if satisfied.
- For example a merge request that fixes a frontend issue should have the
- When you are done with your merge request, remove the WIP prefix and assign the merge request to someone to review and merge it. You can still make changes based on feedback of course, but by removing the WIP prefix it clarifies when the main body of work is completed.
- When a merge request is done, set milestone to the version it should be included in.
- If you are assigned to review and merge a merge request and would like the creator to make somechanges, comment on the merge request and assign it back to the creator. When they have addressed the concern, they will reassign it to the reviewer.
- If you are assigned to merge a merge request and there is a merge conflict, consider trying to resolve ityourself instead of asking the MR creator to resolve the conflict. If it is easy to resolve you avoid a round trip between you and the creator, and the MR gets merged sooner. This is a suggestion, not an obligation.
- If you ask a question to a specific person, always start the comment by mentioning them; this will ensure they see it if their notification level is mentioned and other people will understand they don't have to respond.
- Do not close an issue until it is fully done, which means code has been merged, it has been reportedback to any customers and the community, all issue trackers are updated and any documentation is written and merged.
- When closing an issue leave a comment explaining why you are closing the issue.
- 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.
- The team call is every workday except Friday from 8:30am to 9:00am Pacific Time (mostly 5:30pm - 6:00pm Central European Time).
- We use Blue Jeans for the call since Hangouts is capped at 15 people, link is in the calendar invite.
- The call is recorded automatically, and recordings are automatically deleted after 7 days. Recordings can be found by logging in to the BlueJeans web app, click recordings at the top, and all past recordings show up there. The recordings are private, i.e. only people who are able to log in to the GitLab BlueJeans account can view the recordings. Since you don't have Flash, you'll need to download the recording as an
.mp4file to view it. On some browsers, this requires scrolling to the right to reveal the "Download" button for a given recording, even though a scrollbar may not appear. Make sure the file is downloaded to your encrypted home drive, and delete it after viewing.
- If you have previously logged on to Blue Jeans with different credentials, make sure to log out before joining the call as yourself. You don't need a Blue Jeans account to join the team call.
- We start on time and will not wait for people.
- Person who has first item on the agenda starts the call.
- If you are unable to attend just add your name to the Team 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 that is relevant.
- When done with a point mention the subject of the next item and hand over to the next person.
- We have functional group updates (1 group per call) for the following groups: Marketing, Sid, Product, Sales, Ops, Support, HR, Finance, Development, Front-end, UX/UI.
- We ask 15-20 people per day to share updates about the most exciting thing from your past or upcoming week/weekend. If anyone has something they'd like to talk about, last person in the list will ask the group if they have anything else to share.
- The Team Agenda lists who is meant to speak on which day; this can be altered daily if conflicts arise.
- There is no need to excuse yourself with "I didn't do anything interesting", "I just watched television" or "that's all", it is not a competition. Instead share the most interesting detail, for example what television show you watched, book you are reading, video game you played or what recipe you cooked.
- Sequence of asking people is in order of joining the company, same as on the team page. If there are non-team page people in the call we end with those.
- It is OK to talk over people or interrupt people to ask questions, cheer for them or show your compassion. This to encourage more conversation and feedback in the call.
- 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.
- 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 team agenda and the links from there. We often use the team call to make announcements or discuss changes in processes, so make sure to catch up on the news if you have missed a team call (or more).
- #random 聊天频道是您分享随机的想法，图片，文章等等的地方。当你需要心理休息的时候，这是一个很好的可以去看看的频道。
- 在随机房间可以随时登入登出，可通过开放的Google Hangout视频聊天，任何拥有GitLab电子邮件地址的人都可以按他们的意愿随时进来或离开。 链接在#random聊天频道的描述中; 考虑将其加入书签。 这个房间是开放的并与咖啡休息电话不同，它在队友之间进行的1x1对话。
- If you want to ask team members if they are available for an event please send a new calendar appointment from and to the company address. 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.
- If there are materials relevant for a calendar meeting (for example a Google Doc) please add the URL to the meeting invite description.
- 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 install the Google-Calendar-Guests-Can-Modify-Event-By-Default plugin in Chrome to do this automatically.
- If you want to schedule a meeting with a person not on the team please use Calendly.
- 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")
- For smaller meetings we use Google Hangouts, for larger meetings we prefer Blue Jeans (Google Hangouts technical limit is 15 for scheduled meetings).
- For meetings that are scheduled via calendar there is automatically a Google Hangout 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.
- 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 camera and headset, even when they are in the same room. This helps to see the person that is talking clearly on the camera and their name in the list. It also allows people to easily talk and mute themselves. And using a headset prevents an echoing. You wouldn't share an office seat together, don't share your virtual seat at the table.
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.
- Appreciate suggestions and feedback.
- Don't make promises that you can't keep.
- Guide users who ask for help or give a suggestion and share links. Improving Open Development for Everyone, Types of requests.
- When facing negative comment, respond patiently and treat every user as an individual, people with the strongest opinions can turn into the strongest supporters.
Writing Style Guidelines
- Do not use rich text, it makes it hard to copy/paste. Use Markdown instead.
- We use Unix style (lf) line endings, not Windows style (crlf), please ensure
*.md text eol=lfis set in the repository's
git config --global core.autocrlf inputon 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".
- Always use ISO dates in all writing and legal documents,
yyyy-mm-dd, e.g., 2015-04-13, and never 04-13-2015 or 13-04-2015
- 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 URLs, always prefer hyphens to underscores.
- The community include 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'.
- All people working for GitLab the company are the GitLab team, we also have the Core team that is part GitLab team, part volunteers.
- Please always refer to GitLab Inc. people as team members, not employees.
- Always write GitLab with a capitalized G and L, even when writing GitLab.com.
- Monetary amounts shouldn't have one digit, so prefer $19.90 to $19.9
- If an email needs a response write the ask at the top of it.
- Use the future version of words, just like we don't write internet with a capital anymore, we write frontend and webhook without a hyphen or space.
- Our homepage is https://about.gitlab.com/ (with the
- Try to use the active voice whenever possible.
- Please refer to self-hosted installations as on-premises, not on-premise.
- If you use headers properly format them (
##in Markdown, "Heading 2" in Google docs), start at the second header level because header level 1 is for titles, do not end headers with a colon.
- Always use an Oxford comma in lists of three or more terms.
- Read our Documentation Styleguide for more information when writing documentation.
Beamy is our company conference call robot. It lives in the San Francisco Howard St. office. Its main purpose is to allow those outside of the office 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 office. 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 need an invite email to connect and to download a desktop client, please @mention Emily in the #general channel if you don't have the invite yet.
- Beamy times: 8am until 6pm Pacific time on workdays and during all company events, for other times please @mention Sytse in the #valley channel to see if it is OK. It is on auto connect so you'll beam right in.
- 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.
- More info can be found at https://www.suitabletech.com/
- Please report any questions or issues you have about the beam by @mentioning Emily in the #general channel.
如果需要电话号码，请默认将此字段留空。 如果不能留空，请使用通用号码（+ 1-415-761-1791），但请注意，此号码仅仅指向一个语音留言并引导打电话的人通过电子邮件联系我们。
Spending Company Money
In keeping with our values of results, freedom, efficiency, frugality, and boring solutons, we expect team members to take responsibility to determine what they need to purchase or expense in order to do their jobs effectively. We don't want you to have to wait with getting the items that you need to get your job done. You most likely know better than anyone else what the items are that you need to be successful in your job. The guidelines below describe what people in our team commonly expense.
- Spend company money like it is your own money.
- You don't have to ask permission before making purchases in the interest of the company. When in doubt, do inform your manager before the purchase, or as soon as possible after the purchase.
- It is uncommon for you to need all of the items listed below, use your best judgement and buy them as you need them. If you wonder if something is common, feel free to ask People Ops (and in turn, People Ops should update the list).
- It is generally easiest and fastest for you to make the purchases yourself, but feel free to reach out to People Ops if you would like help in acquiring some items. Just include a link and your shipping address in an email, and People Ops will be happy to place the order.
- Employees: file your expense report no later than 7 days after the end of the calendar quarter that you made the purchase in. Contractors: include receipts with your invoices.
- Any non-company expenses paid with a company credit card will have to be reported to your manager as soon as possible and refunded in full within 14 days.
- Items. The company will pay for the following items if you need it for work or use it mainly for business, and local law allows us to pay for it without incurring payroll taxes. Items paid for by the company are property of the company and need to be reported with serial numbers etc. to People Ops for properasset tracking. Links in the list below are to sample items, other options can be considered:
- Notebook: we recommend getting a MacBook Pro 13-inch retina with 512GB of storage and 16GB of memory for engineers and a Macbook 256GB for non-engineers. Running Unix makes it easier to work with git from the command line so we strongly recommend against Windows laptops. WebEx screen sharing does not work from a Linux platform while it is one of the more common conferencing tools used with customers that we all need to interact with from time to time. Additionally 1password doesn't have a native client for Linux and the web interface in Firefox is not that good. If you have strong reasons to want to deviate from this guideline just ask your manager.
- Notebook carrying bag
- External monitor, monitor-cable,
- Ethernet connector
- Keyboard and mouse set
- Height adjustable desk
- Ergonomic chair
- Work-related books
- Mobile phone, we commonly pay for an iPhone SE if you travel a lot as a Developer Advocate.
- Something else? No problem, and consider adding it to this list if others can benefit as well.
- Expenses. The company will reimburse for the following expenses if you need it for work or use it mainly for business, and local law allows us to pay for it without incurring taxes:
- Mileage is reimbursed according to local law: US rate per mile, or rate per km in the Netherlands.
- Internet connection, for employees in the Netherlands see Regeling Internet Thuis
- Mobile subscription, we commonly pay for that if you call a lot as a salesperson or executive.
- Telephone land line (uncommon, except for positions that require a lot of phone calls)
- Skype calling credit, we can autofill your account (uncommon, since we mostly use Google Hangouts, BlueJeans, and WebEx)
- Google Hangouts calling credit
- Office space (if working from home is not practical)
- Work-related online courses
- Work-related conferences, including travel, lodging and meals. If total costs exceed $500, please submit a proposal and get permission from your manager.
- Travel and lodging to get together with colleagues and work on a specific project, with a minimum of 3 team members present and 3 days of co-location. Meals are generally not covered out of fairness to any people already on location. If total costs exceed $300, please submit a proposal to your manager and get permission from them and the VP of your department.
- Business travel upgrades per round-trip (i.e. not per each leg of the flight):
- Something else? No problem, and consider adding it to this list if others can benefit as well.
- Expense Reimbursement
- If you are a contractor, please submit an invoice with receipts attached to email@example.com.
- If you are an employee, GitLab uses Expensify to facilitate the reimbursement of your expenses. As part of onboarding you will receive an invitation by email to join GitLab's account. Please set up your account by following the instructions in the invitation.
- If you are new to Expensify and would like a brief review, please see Getting Started
- For step by step instructions on creating, submitting and closing a report please see Create, Submit, Close
- If you are an employee with a company credit card, your company credit card charges will automatically be fed to a new Expensify report each month. Please attach receipts for these expenses (per the Expense Policy, see below) within 5 business days after the end of the month. These amounts will not be reimbursed to you but Expensify provides a platform for documenting your charges correctly.
- Expense Policy
- Max Expense Amount - 5,000 USD or 5,000 EUR
- Receipt Required Amount - 25 USD or 25 EUR
Paid Time Off
- Don't frown on people taking time off, but rather encourage that people take care of themselves and others.
- Working hours are flexible, you are invited to the team call if you are available, and we encourage you to post to the #working-on chat channel when you start your day so others can offer suggestions.
- You don't need to worry about taking time off to go to the gym, take a nap, go grocery shopping, doing household chores, helping someone, taking care of a loved one, etc. If something comes up or takes longer than expected and you have urgent tasks and you're able to communicate, just ensure the rest of the team knows and someone can pick up any urgent tasks.
- We have an "unlimited" time off policy. This means that:
- You do not need to ask permission to take time off unless you want to take more than 25 consecutive calendar days.
- Always make sure that your job responsibilities are covered while you are away.
- We strongly recommended to take at least a minimum of 2 weeks of vacation per year, if you take less your manager might follow up to discuss your work load.
- You do need to ensure that not more than half of the people that can help with availability emergencies (the on-call heroes), regular support, sales, or development are gone at any moment. You can check for this on the availability calendar, so be sure to add appointments early.
- Please see the PagerDuty page for information on how to handle scheduled leave for someone from theon-call team.
- Add an appointment to the GitLab availability calendar as you know your plans, you can always change it later.
- In case it can be useful add your planned time off as a FYI on the next agenda of the team call.
- We will help clients during official days off, unless they are official days off in both the Netherlands and the U.S. We try to have people working who are in a country that don't have an official day off. If you need to work during an official day off in your country, you should take a day off in return.
- If you have to respond to an incident while being on-call outside of your regular working hours, you should feel free to take off some time the following day to recover and be well-rested. If you feel pressure to not take the time off to rest, refer to this part of the handbook and explain that you had to handle an incident.
The following incentives are available for GitLab team members.
Sales Target Dinner Evangelism Reward
Since reaching sales targets is a team effort that integrates everything from making a great product to providing top notch customer support and everything in between, we reward all team members for every month that we reach our Sales Targets. The incentive is 100 USD to each team member for the purpose of evangelizing the GitLab story. You may use the incentive at a restaurant of your choice. Enjoy!
- The CEO, or CRO will announce on the team call if the target was met.
- To claim the incentive, please submit your receipt through Expensify or include on your contractor invoice as a reimbursable expense.
- Indicate on your receipt and in the comment section in expensify "GitLab evangelism" and the names of the other particpants.
- You should spend the incentive on eating out, and can be reimbursed up to the maximum of 100 USD.
- Use the incentive in the month following the announcement. So for example, if we reach our target in March, use your incentive in April.
- If you cannot, or decide not to, use the incentive in the expected month, you can carry it over to the next month by notifying Accounts Payable before the 22nd of the month (release day!). You can only carry over one month in this way.
- Every now and then, individual team members really shine as they go above and beyond their regular responsibilities and tasks.
- We recognize this through the #thanks channel, and sometimes also through a discretionary bonus.
- Managers can recommend their team members to the CEO for a $1,000 bonus.
- On team call, the manager announces the “who” and “why” of the bonus; and the "why" should be tied to our values.
- The manager should send a brief email that explains the bonus (same as the team call blurb) and states the amount to People Ops and our Controller who will process the information into payroll and BambooHR. People Ops should confirm when these steps have been taken, back to the manager.
- If you think you are meeting the requirements for another title, want to change jobs within the company, or think your growth should be reflected in your compensation please feel free to discuss with your manager.
除非另有说明，否则签名的文件应发送给发送请求签名的人员。 该文档将通过HelloSign（一种基于云的电子签名工具）进行管理。 只有C级管理人员可以签署法律文件，除了涉及另一组织的物理访问的NDA。
远程和异步工作的最大优势可能是它提供的灵活性。 这使得将工作与您的个人生活结合起来很容易，尽管可能难以找到适当的平衡。 这可以通过明确规划您的休假时间或计划您的工作来缓解。 当您不工作时，建议您关闭Slack并关闭您的电子邮件客户端，使其无法使用。 同事们应该通过遵守通信准则来使其工作。
如果你以前在办公室工作，现在你却不能和从前那样和你默认的小组一起共进午餐。 从不同的角度来看，现在你可以选择与你一起吃午餐的人和不与你一起吃午餐的人。 有一段时间没有和一个好朋友说话了吗？ 现在你可以和他一起吃午餐了。
理解远程工作导致了GitLabbers同胞之间进行大部分与工作有关的对话，每个人都被鼓励每周几小时致力于与任何GitLab员工进行社交呼叫 - 以了解与您一起工作的人，谈论日常事务并共享一杯虚拟咖啡。我们希望您与您合作的人交朋友并建立关系，创造一个更加舒适，全面的环境。 咖啡休息电话与随机房间视频聊天不同，它们旨在为您提供与您希望说话的特定队友进行1x1电话的选项，而不是随机的，全开的频道，而是两个队友之间的对话。
我们使用的许多工具都在手册的其余部分中描述过 (GitLab, Google Docs, Google Hangouts, 1Password, etc.). 这部分是不适合其他地方的工具.
- 设置一个Calendly 账户
- 链接到 GitLab 谷歌日历为你创造一个日程表
- 所有的会议都会有相同的谷歌Hangout URL在您的日历基于你 @gitlab.com 邮件处理. 您可以使用上面的预订文本. 在你的日历事件都会自动添加谷歌Hangout URL, 所以你可以使用 附加登陆页面快速进入电话. 请注意，约会将显示在其他人日历与不同的链接, 您必须在下面指定的时间段设置文本链接.
- 设置与文本的45分钟的时间间隔： "这将是一个在谷歌Hangout https://plus.google.com/hangouts/_/gitlab.com/XXXXX Question? 请给我发电子邮件. GitLab Primer: https://about.gitlab.com/primer/"
- 对于没有注册GitLab Inc的人, 把你的calendly链接，直接链接到45分钟的时间: "Are any of the times on https://calendly.com/XXXXX/45min/ convenient for you? 如果是就标记一个, 如果没有，请让我知道什么时候对你有好处，我们会找到另一种选择."
- 更新您的可用性 Calendy Event Types
- 考虑到你添加你calendly链接 Slack profile 对于 显示文本，使用此线:
添加一个日程安排和我!所以团队成员可以安排 a 1:1 打电话给你gitlab，通过简单的点击你的链接在你calendly轮廓松弛.
4.99美元的OSX工具，允许您使用fn键作为推送或静音。 您再也不必将切换窗口焦点放在Google Hangout或 Blue Jeans以说话或静音。 该图标将显示您的麦克风输入的当前状态（x表示静音）。 通过右键单击，您可以从一键转换切换到静音。 加入后，请勿忘记在Blue Jeans/Google Hangouts中立即取消屏蔽您的麦克风。 警告，使用page up和fn+向下箭头将激活它。 使用空格或page down而不是fn+向上箭头。
通过选项快速禁用通知中心 - 单击屏幕右上角的菜单栏图标。 这将禁用通知，直到第二天。 选项 - 再次单击以立即重新启用。 或者，单击通知中心图标，然后向上 滚动以显示“请勿打扰”切换。
- 点击“使用此搜索创建过滤器（Create filter with this search）”
- 选中“应用标签（Apply the label:）：”，然后选择要添加的标签，或者创建一个新的标签，如“提到（Mentioned）”
- 选中“同时将过滤器应用于匹配的对话（Also apply filter to matching conversations）”。
- 点击“创建过滤器（Create filter）”
如果您使用归档功能，则通常返回到概述。 使用自动前进功能可以返回到下一条消息。 在设置下的labs部分启用“自动前进（Auto-advance）”。 显示下一个较旧消息的默认设置是OK。
在Chrome Hangouts 中，由于使用vp9编解码器，所以会消耗100％的CPU。 在MacOS中切换到Safari可以解决这个问题，因为它将使用硬件加速的h264编解码器。
潜在的问题：即使我以GitLab的身份登录并且在电话下面找到了这个栏，我也无法切换直播！ 我确实注意到时间设定不（再？）正确。 我以前做了一个测试事件，似乎工作正常。 我再试一次，看看它是否有效。
Go to => life streaming => events and create a new one with the attributes:
- type => quick (using Google Hangouts on Air)
- advanced: promotions: disable both checkboxes
- time needs to be set correctly
The view on watch page URL only allows for people to watch it. Window that pops up when you press the start hangout on air button has the proper URL that you can send to other people and/or add it to the calendar invite, it is structured like: https://plus.google.com/hangouts/_/ytl/LONGHASH. When people join the event they have to accept a warning.
Completed live events will show the video and you can click the image to view it. You can use actions to make it public here
One Tab 将选项卡命名为可以排序和导出的列表。
TripMode 允许您控制哪些应用可以使用互联网。 当您使用蜂窝/计量连接时特别有用。
Check which process occupies a given port
When the GitLab Development Kit cannot start using the
./run command and Unicorn terminates because port 3000 is already in use, you will have to check what process is using it. Running
sudo lsof -i -n -P | grep TCP | grep 3000 will yield the offender so this process can be killed. It might be wise to alias this command in your
.bash_profile or equivalent for your shell.
If you install MobileDay on your phone and give it access to your Google Calendar it can dial into conference calls for you. It is very good at detecting the number and password from the calendar invite.
这是您需要在计算机上安装并运行以获取Git并运行它所需的指南，以便您可以在几分钟内创建您的第一个MR（Merge Request）！ 按照以下编号步骤完成设置。
- 执行：git --version检查您的Git版本。
- 如果未安装Git，则应提示您进行安装。 按照本指南安装Git并将您的帐户链接到Git。
3. 安装 RVM
- 请访问 https://rvm.io.
curl -sSL https://get.rvm.io | bash -s stable.
4. 安装 Ruby 和 Bundler
rvm install 2.2.1安装 Ruby 语言开发环境 (如果有提示的话请输入你的系统密码).
rvm use 2.2.1 --default用来设置默认的 Ruby 为
ruby --version验证 Ruby 安装是否成功。你将看到:
ruby 2.2.1p85 (2015-02-26 revision 49769).
gem install bundler安装 Bundler.
git clone https://gitlab.com/gitlab-com/www-gitlab-com.git克隆网站.
bundle install安装所有 gem 依赖
这个问题主要是针对使用 OS X 系统的用户。为了驯服这个问题可执行命令
git config --global core.autocrlf input -
关于如何更新网站的详细信息请阅读 readme of www-gitlab-com.
bundle exec middleman.。
- 要在本地编辑网站，您需要安装文本编辑器。 我们推荐Sublime Text 3 或 Atom。