Fix typos in www-gitlab-com entire project

source/handbook/engineering/fast-boot/index.html.md

@@ -47,7 +47,7 @@ with followup surveys.
 During the Fast Boot, you should record and livestream videos that give people
 insight into what your team is working on. Kickoff meetings, working sessions,
 and demos are all great candidates for being livestreamed. If there are
-deliverables from a working session, such as a UX excercise, you should
+deliverables from a working session, such as a UX exercise, you should
 include those. You should also consider what artifacts you need to aggregate
 and communicate the success of the fast boot once it is done.

source/handbook/engineering/infrastructure/blueprint/ci-cd/index.html.md

@@ -219,6 +219,6 @@ Rather than putting together a grand plan to dogfood CI/CD, let's deploy our [va
   challenge to pursue as we scale GitLab and GitLab.com.
 * **Results: Bias for Action**
 * **Efficiency: Boring Solutions** Using GitLab CI/CD *is* a boring solution.
-* **Efficency: Minimum Viable Change** Let's identify and deliver on MVCs.
+* **Efficiency: Minimum Viable Change** Let's identify and deliver on MVCs.
 * **Iteration: Make a Proposal** [Recursive](./).
 * **Transparency: Public by Default** [Also recursive](./).

source/handbook/engineering/infrastructure/blueprint/service-levels-error-budgets/index.html.md

@@ -20,7 +20,7 @@ As noted on chapter 3 of the *Site Reliability Engineering* book, *Embracing Ris
 > Site Reliability Engineering seeks to balance the risk of unavailability with the goals of rapid innovation and efficient service operations, so that users’ overall happiness—with features, service, and performance—is optimized. [...] Our goal is to explicitly align the risk taken by a given service with the risk the business is willing to bear.
-We embrace risk by striving to manage it, and we must do so in **a stuctured, data-driven fashion** to achieve an **optimal, predictable, sustainable and safe speed of change**, tying together our availability and feature development  commitments to our users with our organizational ability to execute on those commitments.
+We embrace risk by striving to manage it, and we must do so in **a structured, data-driven fashion** to achieve an **optimal, predictable, sustainable and safe speed of change**, tying together our availability and feature development  commitments to our users with our organizational ability to execute on those commitments.
 We must properly define the actual **meaning of *uptime***, and we have to implement **the framework** through which said metric is calculated, tracked and evaluated. This is meaninless unless we also define the associated agreements on how we dial the speed of change to meet our availability objectives. This represents a company-wide commitment to the framework.
@@ -94,7 +94,7 @@ Rather than putting together a grand plan to implement the service levels and er
 * **Results: Ambitious** This is a significant change to our development and infrastructure culture, a worthy challenge to pursue as we scale GitLab and GitLab.com.
 * **Results: Bias for Action** We have already started to work on this, but we need to make progress.
 * **Efficiency: Boring Solutions** Service levels and error budgets are industry-wide best practices.
-* **Efficency: Minimum Viable Change** Let's identify and deliver on MVCs.
+* **Efficiency: Minimum Viable Change** Let's identify and deliver on MVCs.
 * **Iteration: Make a Proposal** [Recursive](./).
 * **Transparency: Public by Default** [Also recursive](./).

source/handbook/engineering/infrastructure/career/index.html.md

@@ -44,7 +44,7 @@ Think about the areas that are important to you and commmit to working on them o
 ## Guidelines and Considerations
-Career development requires that all parties involved be commited to the process and are active participants.
+Career development requires that all parties involved be committed to the process and are active participants.
 One implicit area to focus on explicitly is **communication**. Regardless of your role, whether tehnical or manager, you must be a good communicator, and thus, it is important to always improve our communication skills.

source/handbook/engineering/infrastructure/design/cicd-pipeline/index.html.md

@@ -32,7 +32,7 @@ the release.
 ## Release timeline of 10.3
-_Staging and canary deployments ommitted_
+_Staging and canary deployments omitted_
 - RC1: Sept 3rd
 - RC2: Sept 5th

source/handbook/engineering/infrastructure/design/disaster-recovery/index.html.md

@@ -49,7 +49,7 @@ can publish and test against these metrics.
 **Recovery Point Objective ([RPO](https://en.wikipedia.org/wiki/Recovery_point_objective))** : maximum targeted period in which data might be lost due to a major incident
 **Recovery Time Objective ([RTO](https://en.wikipedia.org/wiki/Recovery_time_objective))** : targeted duration of time and service level within which a business process much be restored
-after a disaster to avoid unacceptable consequences of a break in busines continuity
+after a disaster to avoid unacceptable consequences of a break in business continuity
 ### GitLab.com's Data

source/handbook/engineering/infrastructure/design/git-workflow/index.html.md

@@ -13,13 +13,13 @@ Issue: [`gitlab-com/gl-infra/infrastructure#5276`](https://gitlab.com/gitlab-com
 ## Idea/Problem Statement
-In order for CI/CD to automatically deploy the GitLab.com application and infrastructure to staging and production environments, there need to be controls in place to ensure that every state change is recorded, repeatable, and reversable.  Luckily `git` gives us all of the tools that we need, if we design our workflow sensibly.
+In order for CI/CD to automatically deploy the GitLab.com application and infrastructure to staging and production environments, there need to be controls in place to ensure that every state change is recorded, repeatable, and reversible.  Luckily `git` gives us all of the tools that we need, if we design our workflow sensibly.
 The problems that we need to solve are:
-- Everything needs to be tested in staging (and possably again in canary) before being deployed to production
+- Everything needs to be tested in staging (and possibly again in canary) before being deployed to production
 - What is deployed in production must be exactly what was tested in staging, with no possibility of exceptions
-- Any change to production must be easily reversable to a known prior state
+- Any change to production must be easily reversible to a known prior state
 - It must be easy to test changes which are not yet ready to be evaluated in staging
@@ -35,8 +35,8 @@ This model can be used for infrastructure (terraform/chef) changes, as well as a
 - `master` is always deployable, and is deployed automatically to staging on each merge.
 - Merge requests from feature and issue branches  ALL target the `master` branch - never `production`
 - The `master` branch is tagged when a version is judged to be ready for production.
-- This tag (repeatable state) is used to create an MR targetting the `production` branch
-- Rollbacks to the immediate prior version consists of creating a new merge request for the previous tag, targetting the `production` branch. For rollbacks to earlier versions, we use `git revert` or create a new incremented version with the necessary changes to correct/revert the problematic change.
+- This tag (repeatable state) is used to create an MR targeting the `production` branch
+- Rollbacks to the immediate prior version consists of creating a new merge request for the previous tag, targeting the `production` branch. For rollbacks to earlier versions, we use `git revert` or create a new incremented version with the necessary changes to correct/revert the problematic change.
 - Hotfixes are implemented as branches based on the tag which is in production. This branch is changed and tagged *in the hotfix branch* before being merged to `production`. That way the tag doesn't include any subsequent work and can be deployed to `production` cleanly.
 - Changes which are not ready for staging remain in feature branches, and are tested in ephemeral environments.
@@ -61,9 +61,9 @@ git merge master
 git push origin production
 ```
-It may be advantagious for the scripting to check and only deploy tagged versions to production.
-The canary environment can be treated as a separate branch, or as the target of the CI/CD for `production`, with a manual step to propogate approved tags to production.
+It may be advantageous for the scripting to check and only deploy tagged versions to production.
+The canary environment can be treated as a separate branch, or as the target of the CI/CD for `production`, with a manual step to propagate approved tags to production.
 ####  Monitoring

source/handbook/engineering/infrastructure/design/zfs-filesystem/index.html.md

@@ -171,12 +171,12 @@ Since we are going to be retooling the underlying filesystem of the node archite
 it only make sense to look at the way that we are generating nodes. Currently
 today we start from a base linux image and bootstrap it into Chef, then build all
 of our customizations and dependencies per-node. This is repetative work and no 
-longer efficent when talking about desiring to have auto-scale services and with
+longer efficient when talking about desiring to have auto-scale services and with
 and eye towards kubernetes. With this project we would like to create a CI/CD pipeline
 that leverages Packer to produce GCP disk images that are 'feature complete' to
 be boostraped into needed purposses. This means that we would produce a GCP disk
 image that already had the latest kernel, patches, require software, configuration
-and was ready to be bootstrapped into an indivudual node role (i.e. sidekiq, web, git).
+and was ready to be bootstrapped into an individual node role (i.e. sidekiq, web, git).
 #### Build Process Improvement
 We would also leverage our current Consul installation to provide three destinct

source/handbook/engineering/infrastructure/director/notebook/index.html.md

@@ -13,7 +13,7 @@ title: "Notebook"
 The **workload workflow** plots the overall approach to planning and managing our workload across all levels in the department, from the director through managers to individual contributors. 
-In terms of **planning**, the director and the managers use OKRs to define objectives and priorities in a top-down fashion. The managers and individual contributors take said OKRs as inputs to define epics to break down the work into well-defined blocks. These epics can be broken into additonal epics or individual issues as necessary. In terms of **execution**, bi-weekly milestones are used to manage sprints of work.
+In terms of **planning**, the director and the managers use OKRs to define objectives and priorities in a top-down fashion. The managers and individual contributors take said OKRs as inputs to define epics to break down the work into well-defined blocks. These epics can be broken into additional epics or individual issues as necessary. In terms of **execution**, bi-weekly milestones are used to manage sprints of work.
 ### OKRs

source/handbook/engineering/infrastructure/meeting/index.html.md

@@ -56,7 +56,7 @@ During discussions, it is obviously ok to point shortcomings for a given design.
 ### Staff Meeting
-Each team in Infrastructure has a weekly Staff meeting, where relevent team issues are discussed. These meetinfs are organized by Infrastructure Managers for their respective teams.
+Each team in Infrastructure has a weekly Staff meeting, where relevant team issues are discussed. These meetinfs are organized by Infrastructure Managers for their respective teams.
 #### Agenda

source/handbook/engineering/infrastructure/production-architecture/ci-architecture.html.md

@@ -33,7 +33,7 @@ In each region we have few types of machines:
   by `gitlab-shared-runners-manager-X` and `private-runners-manager-X` are
   re-used. However, machines created by `shared-runners-manager-X` are removed
   immediately after the job is finished.
-- **Helpers** - hosts that provide auxillary services such as monitoring and
+- **Helpers** - hosts that provide auxiliary services such as monitoring and
   cache.
   - **Prometheus** - Prometheus servers in each region monitor machines.
   - **Runners Cache** - Caches job data and images from Docker Hub (**DO ONLY**)

source/handbook/engineering/infrastructure/team/delivery/index.html.md.erb

@@ -15,7 +15,7 @@ title: "Delivery Team"
 | **Slack Channels** | [#sre-lounge](https://gitlab.slack.com/archives/sre-lounge), [#database](https://gitlab.slack.com/archives/database) | [#alerts](https://gitlab.slack.com/archives/alerts), [#production](https://gitlab.slack.com/archives/production) | [#g_delivery](https://gitlab.slack.com/archives/g_delivery)
 | **Operations** | [Runbooks](https://gitlab.com/gitlab-com/runbooks) (please contribute!) | **On-call**: [Handover Document](https://docs.google.com/document/d/1IrTi06fUMgxqDCDRD4-e7SJNPvxhFML22jf-3pdz_TI), [Reports](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues?scope=all&utf8=%E2%9C%93&state=closed&label_name[]=oncall%20report) |
-## Top-level Responsibilties
+## Top-level Responsibilities
 * Acting as Release Managers for our monthly .com release process
 * Migrate the company to a continuous delivery model (through automation)

source/handbook/engineering/infrastructure/team/index.html.md.erb

@@ -18,7 +18,7 @@ title: "Team"
 ## Teams
-An operational environment is a complex and interconnected mesh of components working in unison to deliver a set of services. In a prior iteration of the teams, we purposedly avoided organizing teams along siloed functional groups, aligning them instead along the environment's **lifecycle**,
+An operational environment is a complex and interconnected mesh of components working in unison to deliver a set of services. In a prior iteration of the teams, we purposely avoided organizing teams along siloed functional groups, aligning them instead along the environment's **lifecycle**,
 taking into account the two variables that drive change into the environment: time and space.
 ### Structure

source/handbook/engineering/monitoring/index.html.md

@@ -89,7 +89,7 @@ For monitoring system performance and metrics Grafana is still the preferred int
 Kibana dashboards are used to monitor application activity, spam events, transient errors, system and network authentication
 events, security events, etc. Commonly used dashboards are the Abuse, SSH, and Rack Attack dashboards.
-One can view how we log our infrasturcture as outlined by our
+One can view how we log our infrastructure as outlined by our
 [runbook](https://gitlab.com/gitlab-com/runbooks/blob/master/howto/logging.md)
 ### Adding dashboards

source/handbook/engineering/quality/guidelines/test-engineering/test-design/index.html.md

@@ -22,7 +22,7 @@ This is especially applicable to any exploratory testing performed by both test
 Even simple solutions can have infinite variations to test when we consider the data, timing, environmental or platform factors, configuration, and user behavior following varied sequences actions. We should have as our goal to find the most important and most interesting variations to test, since we cannot possibly test them all.
 ##### Identifying Variables
-Some variables are obvious, some are not. Some are accessible to the end user, some are inderictly accessible, modified only indirectly through changing other variables. For example, size or number of files in a database or number of users logged into a system may affect how a feature functions but are outside of the feature itself and may not be directly modified without specific environments or tools. 
+Some variables are obvious, some are not. Some are accessible to the end user, some are indirectly accessible, modified only indirectly through changing other variables. For example, size or number of files in a database or number of users logged into a system may affect how a feature functions but are outside of the feature itself and may not be directly modified without specific environments or tools. 
 So our goal here is to identify the variables that may play a part in how a particular feature functions and use these as touch points for testing that feature. Since we may have a number of variables to consider, it would be wise to create simple notes to track those variables to make our testing more effective.

source/handbook/engineering/root-cause-analysis/index.html.md

@@ -17,7 +17,7 @@ Your process may be different - but the RCA template is a great starting point.
 ### How are RCAs beneficial?
-RCAs are an opportunity to learn from what went well and what didn't during our workflows; it is not, however, used to promote blame or point fingers. These are blameless reviews of the workflows and processes taken during a project to enhance learning from our experiences and more dynamic iteration in our processes. Issues can be worked on invididually or in a team, and often involve cross-team collaboration. RCAs allow everyone to learn from the mistakes and successes - no matter the involvement (or-lack-thereof) in the issue - across the entire organization. GitLab utilizes RCAs to consolidate project information which further improves their utility as a single source-of-truth for a project after its completion.
+RCAs are an opportunity to learn from what went well and what didn't during our workflows; it is not, however, used to promote blame or point fingers. These are blameless reviews of the workflows and processes taken during a project to enhance learning from our experiences and more dynamic iteration in our processes. Issues can be worked on individually or in a team, and often involve cross-team collaboration. RCAs allow everyone to learn from the mistakes and successes - no matter the involvement (or-lack-thereof) in the issue - across the entire organization. GitLab utilizes RCAs to consolidate project information which further improves their utility as a single source-of-truth for a project after its completion.
 While each team is unique in their function, the ability to learn from our past performances across the GitLab organization allows us to transform our approach to solving problems, iterate our processes based on data, and help prevent us from making the same mistakes over and over again.

source/handbook/engineering/security/index.html.md

@@ -448,7 +448,7 @@ If admin-level access is being requested, the request must be approved by the te
 In the case of a separation from the company, all access will be deprovisioned within 3 business days from the date on which the offboarding request is submitted unless otherwise specified.
-All attemps will be made for individual access removal requests to be processed within the SLA requested. If no SLA is noted, access will be deprovisioned within 3 business days of the submission of the issue.
+All attempts will be made for individual access removal requests to be processed within the SLA requested. If no SLA is noted, access will be deprovisioned within 3 business days of the submission of the issue.
 If access removal needs to occur immediately, please follow the [panic email procedures](https://about.gitlab.com/handbook/security/#panic-email), which will alert the Security Team on-call.
@@ -560,7 +560,7 @@ The purpose of adding Admin Notes allow us to better assist the Support Team and
 ## DMCA Requests
-The Security Team plays a big role in defining the procedures and reviewing Digital Millenium Copyright Act (DMCA) requests.  All DMCA requests need to be vetted by Legal first before any further steps are taken to proceed with the take down of reported content.  Reported content that has been sucessfully vetted by Legal must be referred to the Abuse Team before any action is taken.
+The Security Team plays a big role in defining the procedures and reviewing Digital Millennium Copyright Act (DMCA) requests.  All DMCA requests need to be vetted by Legal first before any further steps are taken to proceed with the take down of reported content.  Reported content that has been successfully vetted by Legal must be referred to the Abuse Team before any action is taken.
 #### For DMCA requests the Abuse Team will follow the below process
@@ -568,7 +568,7 @@ The Security Team plays a big role in defining the procedures and reviewing Digi
 - Temporarlily remove the content to allow the parties to commence litigation.
 - Return the content to the original state if no litigation was commenced.
-Abuse works in conjuction with Legal referencing the [DMCA Removal Workflow](https://about.gitlab.com/handbook/engineering/security/dmca-removal-requests.html)
+Abuse works in conjunction with Legal referencing the [DMCA Removal Workflow](https://about.gitlab.com/handbook/engineering/security/dmca-removal-requests.html)
 ## Vulnerability Reports and HackerOne
@@ -732,7 +732,7 @@ GitLab awards swag codes for free GitLab swag to any reports that result in a se
 Even though many of our 3rd-party dependencies, hosted services, and the static
 `about.gitlab.com` site are listed explicitly as out of scope, they are sometimes
-targetted by researchers. This results in disruption to normal GitLab operations.
+targeted by researchers. This results in disruption to normal GitLab operations.
 In these cases, if a valid email can be associated with the activity, a warning
 such as the following should be sent to the researcher using an official channel
 of communication such as ZenDesk.

source/handbook/engineering/ux/index.html.md

@@ -78,7 +78,7 @@ UX should assist in driving the [product vision](/direction/product-vision/) ear
 Though we structure our work around individual stages of the product (Plan, Manage, Create, etc.) we should not separate look, feel and process from what the user is trying to accomplish. We must maintain a focus on what the user needs to get done and how to deliver that in the most effective manner possible. This includes how users flow from one stage of the product to another. Maintaining a holistic overview of the path a user may take allows us to see the possible twists and turns along the way. With this knowledge, we can optimize the user experience.
-It is the responsibiliy of each [Product Designer](https://about.gitlab.com/job-families/engineering/product-designer/) to understand how users may flow in and out of their area of focus.
+It is the responsibility of each [Product Designer](https://about.gitlab.com/job-families/engineering/product-designer/) to understand how users may flow in and out of their area of focus.
 **Experience Baselines and Recommendations** <br>
 Designers use [Experience Baselines](https://about.gitlab.com/handbook/engineering/ux/experience-baseline-recommendations) to benchmark common user tasks. In many cases, tasks involve multiple stages of the product, giving designers visibility into how users traverse across stages. Designers follow with [Experience Recommendations](https://about.gitlab.com/handbook/engineering/ux/experience-baseline-recommendations) for how to improve the experience in upcoming milestones.

source/handbook/engineering/ux/pajamas-design-system/index.html.md

@@ -31,7 +31,7 @@ Pajamas enables anyone to contribute towards GitLab. It allows Product, Engineer
 **It’s efficient.**
 - Product Designers can spend more time solving problems and less time designing (and redesigning) UI components. Components can be reused, making design efforts scalable and ensuring our UI stays [DRY](https://deviq.com/don-t-repeat-yourself/).
 - Engineers can reference design documentation that enables them to easily eliminate inconsistencies between design and code without assistance from a Product Designer.
-- Engineers can find coding and development guidelines which will enable them to write better code and conform to set practices more effeciently.
+- Engineers can find coding and development guidelines which will enable them to write better code and conform to set practices more efficiently.
 - Product Managers can quickly propose solutions that follow documented usability guidelines.
 **It creates a cohesive product.**

source/handbook/finance/accounting/index.html.md

@@ -377,7 +377,7 @@ If a team member would like to purchase an asset from the company (i.e. a laptop
 1. Review the week # and check date
 1. All salary team members are set up with autopaid for 86.67 hours per check date.
 1. Create a batch for hourly employees, LOA, new hires, and/or termination
-1. Create a batch for one time payment (referal bonus, discretion bonus, commission, SDR bonus, and quarterly bonus) as check number #2 or 3 with Bonus frequency
+1. Create a batch for one time payment (referral bonus, discretion bonus, commission, SDR bonus, and quarterly bonus) as check number #2 or 3 with Bonus frequency
 1. Create a batch for benefits corrections as needed
 1. Be sure to enter W under Special action column in the one time payment batch to cancel the calculation of GTL
 1. Generate payroll reports (employee changes, paydata summary) PDF format
@@ -931,7 +931,7 @@ Factors that are considered in determining the time of recording accrued liabili
 #### Procedural
 The Finance team is responsible for having procedures in place to reconcile accounts monthly and for keeping documentation to support accrued liabilities. Payables and accrued liabilities are recorded at face value, plus or minus any applicable adjustments. In most cases, the payable amount can be determined from the vendor bill. If not, then the amount should be verified against any relevant documents before recording the liability. When actual values are not available, the recorded value should be based on best available estimates. Estimates should be based on current market price and experience/history.
-1.  Legal Professional Fees:  Monthly templates are e-mailed by the 1st to all legal firms requesting them to complete with all outstanding bills and unbilled services as of that month end (ex. e-mails are sent by April 1st requesting services as of March 31st).  The responses from all legal firms are complied and and reviewed with the VP of Legal - Commerical, IP & Compilance by the 5th, and accruals are made based on the responses and review.  In addition, any potential legal contigencies are discussed during the monthly meeting with the VP of Legal and an accrual is recorded if the loss is deemed probable and the amount can be reasonably estimated.
+1.  Legal Professional Fees:  Monthly templates are e-mailed by the 1st to all legal firms requesting them to complete with all outstanding bills and unbilled services as of that month end (ex. e-mails are sent by April 1st requesting services as of March 31st).  The responses from all legal firms are complied and and reviewed with the VP of Legal - Commercial, IP & Compliance by the 5th, and accruals are made based on the responses and review.  In addition, any potential legal contigencies are discussed during the monthly meeting with the VP of Legal and an accrual is recorded if the loss is deemed probable and the amount can be reasonably estimated.
 2.  Tax and Audit Professional Fees:  Similarlily e-mails with the template are sent to the tax and audit firms and the tax responses are compiled and reviewed with the Director of Tax and the audit firm responses are reviewed with the Accounting and External Reporting Manager by the 5th and appropriate accruals are made based on the review.
 The Sr. Accounting Manager is responsible for performing an overall review of accrued liabilities, one to three business days after accounts payable closes each month, to help ensure that all expenses are captured accurately.