<aside> ℹ️ This is a glossary of terms you might hear working at Sourcegraph. Although we try to minimize the use of acronyms, they do appear from time to time and this can be a helpful resource to figure out what people are talking about. In your day to day, try to avoid using them, or at least explain them the first time you use them.

</aside>

Technical Terms

Note: It’s written as “one box” not “OneBox” or “One Box” because it is just a place holder term, not a proper noun or approved brand. | | Noodle | The code name we used internally at Sourcegraph for the tiger team who worked on early iterations of the unified product (where there's one box for search and chat) as more and more of EPD department work on that one box, this team will disband. |

Teams and Titles

Business Terms

General Terms

Developer lingo for non-developers: a guide

This guide is made to define and explain many of the terms that are commonplace in conversations at the Sourcegraph office but not necessarily outside of it. The goal of this guide is to break down these terms in a way that your average person can comprehend, at least at a very high level. Think of this as an "intro to dev-speak" :)

For example, if you have a recipe for cookies that you want to share with others, so you share it in a public blog– anyone now has the ability to read it, make it, and modify it for whatever they want. | | IDE (Integrated Development Environment) | A software development tool that is similar to an editor, but has other necessary tools (debugger, tester, compiler, etc.) integrated. Imagine a Google Doc that has tools built in for error detection, previews, and language translation. | | Code Host | A service like GitHub, GitLab, or Bitbucket which provides storage and remote access to code. It's basically where your code lives. | | Version Control | A system that tracks changes to a document or project over time in an orderly and systematic way. This is similar to how a Google Doc allows you to review a document’s history (see what changes occurred, who made which changes, etc.) Version control provides the ability to “time travel” and restore previous versions of the document in case something went wrong with one of the changes. | | Git | A version control system, developed for the maintenance of code with particularly strong support for simultaneous efforts by many developers. | | README | This is the file outlining the project and is written by the project developers for others to read. It is comparable to a “front page” of a project, where the project is outlined and described by those that worked on it. | | Issue | A report of a possible problem with a project or piece of software. (Just like a real issue!) It is something of concern that you want to flag so it can be corrected. | | Pull Request (AKA "PR") | A request in GitHub for someone else to review your work for any possible errors or flaws before finalizing changes. For example, if you had written an article, and you were almost ready to publish it but first you wanted someone else to review it. They would have the option to provide feedback through comments or approve it for publishing. | | Merge | The act of taking a series of changes in a document or project (commits, for Git) in a branch and applying them to the existing repository. Generally, merging happens once your pull request has been approved. | | Commit | In Git, a single set of changes. This is how you store changes in your repository. | | Repository (AKA "repo") | A collection of (usually related) source code and other files, plus the history of those files. It is a location for your project, similar to a Google Drive folder that stores related documents in one place. | | Branch | A specific series of changes in a repository, usually used to isolate changes during their development. Branching lets you make changes, test them in a staging area, then merge them into the “main branch” (the “live” part of your code). | | Main Branch | The primary branch of a repository, usually holding the actively-developed product and working of features (non-working versions tend to stay in branches). This is the “live” part of a project that can be viewed by the public. Sometimes referred to as the "master" branch. | | Clone | A copy of a repository, including its full history. Similar to a copy of a Google Doc with all its revision history. | | Fork | Making of a new repository which starts as a clone of an existing repository. Usually used to create changes for submission back to the repository, but also used to make a version that has changes that the original repository’s owner won’t include.

For example, if you took a Google Doc template and made a copy of it so you could use it and edit it, but you also altered the original template to add things the original template didn’t include. | | Ship | A word which simply means that you make a feature or product available to customers. | | Dogfood | A word to describe the act of using your own feature or product. Software is often deployed internally for employees to use before going live for customers. | | Markdown | A text markup language to allow plain text to convert to styled text using common conventions, such as _ italics _ or ~~ strikethrough ~~ It's just a shortcut to edit text (bolding, italicizing, underlining, etc.) without having to click the buttons on a toolbar. | | Command Line (AKA "terminal") | A text-based interface for controlling computers by issuing textual commands. Basically, it's a place where you can enter commands for your computer to execute. |