Merge branch 'dmurph-master-patch-73032' into 'master'

Changed instances of 'team-member' to 'team member' on handbook/communication

See merge request gitlab-com/www-gitlab-com!35496

source/handbook/communication/index.html.md

@@ -15,7 +15,7 @@ extra_js:
 ## Introduction
-We're an [all-remote](/company/culture/all-remote/#advantages-for-organizations) company that allows people to work from [almost anywhere in the world](/jobs/faq/#country-hiring-guidelines). We hire great people regardless of where they live, but with GitLab team-members across [more than 60 countries](/company/team/) it's important for us to practice clear communication that helps us stay connected and get things done.
+We're an [all-remote](/company/culture/all-remote/#advantages-for-organizations) company that allows people to work from [almost anywhere in the world](/jobs/faq/#country-hiring-guidelines). We hire great people regardless of where they live, but with GitLab team members across [more than 60 countries](/company/team/) it's important for us to practice clear communication that helps us stay connected and get things done.
 For this, we use **asynchronous communication as a start** and are as open as we can be by communicating through public issues, [merge requests](#everything-starts-with-a-merge-request), and [Slack channels](/handbook/communication/chat),
 and placing an emphasis on ensuring that conclusions of offline conversations are written down.
 When we go **back and forth three times** we jump on a [synchronous video call](/handbook/communication/#video-calls).
@@ -143,14 +143,14 @@ The format is: misused term => correct term, reason why.
 1. CE => Core users, since [CE is a distribution](/handbook/marketing/product-marketing/tiers/#distributions-ce-and-ee) and many Core users use EE.
 1. Hi guys => Hi people, because we want to use [inclusive language](/handbook/values/#inclusive-language--pronouns)
 1. Aggressive => ambitious, since we we want to [attract a diverse set of people](https://www.huffpost.com/entry/textio-unitive-bias-software_n_7493624)
-1. Employees => team-members, since we have team-members who are [contractors](/handbook/people-group/global-compensation/#contract-factor)
+1. Employees => team members, since we have team members who are [contractors](/handbook/people-group/global-compensation/#contract-factor)
 1. Resources => people, since we are more than just our output.
 1. Community => wider community, since [people at GitLab are part of the community too](/handbook/communication/#writing-style-guidelines) and we should see it as something outside the company.
-1. GitLabber => GitLab team-member, since the wider community shouldn't be excluded from being a GitLabber, we [use team-member instead](/company/team/structure/#team-and-team-members).
+1. GitLabber => GitLab team member, since the wider community shouldn't be excluded from being a GitLabber, we [use team member instead](/company/team/structure/#team-and-team-members).
 1. Radical transparency => Transparency, since radical tends to be absolute and we are thoughtful and have [exceptions to transparency](/handbook/general-guidelines/).
 1. Sprint => iteration, since we are in it [for the long-term](/handbook/values/#under-construction) and [sprint implies fast, not quick](https://hackernoon.com/iterations-not-sprints-efab8032174c).
 1. Obviously => skip this word, since using things like "obvious/as we all know/clearly" discourages people who don't understand from asking for clarification.
-1. They => Do not refer to other teams at GitLab externally as "they" (e.g., "Well, they haven't fixed that yet!").  There is no "they" or "headquarters" - there is only us as team-members, and it's one team.  You could instead say something like "The Product team is looking at that issue..."
+1. They => Do not refer to other teams at GitLab externally as "they" (e.g., "Well, they haven't fixed that yet!").  There is no "they" or "headquarters" - there is only us as team members, and it's one team.  You could instead say something like "The Product team is looking at that issue..."
 ### Asking "is this known"
@@ -196,7 +196,7 @@ Most things are **public** unless there is a reason not to. Not public by defaul
    * the Sales pipeline (but the Marketing pipeline can be public)
    * Net and Gross Retention KPIs (only the actual numbers can't be public. Everything else- the goal, their calculation, etc- can be.)
 1. Deals with external parties like contracts and [approving and paying invoices](/handbook/finance/procure-to-pay/).
-1. Content that would violate confidentiality for a GitLab team-member, customer, or user.
+1. Content that would violate confidentiality for a GitLab team member, customer, or user.
 1. Legal discussions are not public due to the [purpose of Attorney-Client Privilege](/handbook/legal/#what-is-the-purpose-of-these-privileges).
 1. Some information is kept confidential by the People Group to protect the privacy, safety, and security of team members and applicants, including applications, background check reports, reference checks, compensation, termination (voluntary and involuntary) details, demographic information, and home address. Whistleblower identity is confidential. People Group policies and processes are public, internally and externally. As examples, [Job families](/handbook/hiring/job-families/) and our [Compensation Calculator](/handbook/people-group/global-compensation/calculator/) are public.
 1. Performance improvement plans, disciplinary actions, as well as individual feedback, are confidential as they contain private negative feedback and [negative feedback is 1-1](/handbook/values/#collaboration) between team members and managers.
@@ -207,7 +207,7 @@ Most things are **public** unless there is a reason not to. Not public by defaul
 1. When we discuss a customer by name that is not public unless we're sure the customer is OK with that. When we discuss a competitor (for example in a sales call) this can be public as our competitive advantages are public.
 1. Competitive sales and marketing campaign planning is confidential since we want the minimize the time the competition has to respond to it.
 1. [Sales battlecards](https://blog.pandadoc.com/the-basics-of-battle-cards/) are not public since we want to minimize the time the competition has to respond to it. Our [feature comparisons](/devops-tools/) are public.
-1. Plans for reorganizations are not public and on a need-to-know basis within the organization. Reorganizations cause disruption and the plans tend to change a lot before being finalized, so being public about them prolongs the disruption. We will keep relevant team-members informed whenever possible.
+1. Plans for reorganizations are not public and on a need-to-know basis within the organization. Reorganizations cause disruption and the plans tend to change a lot before being finalized, so being public about them prolongs the disruption. We will keep relevant team members informed whenever possible.
 1. Discussions that involve decisions related to country of residence are not public as countries are a core part of people's identity and any communication should have complete context.  The output of such decisions, such as [country hiring guidelines](/jobs/faq/#country-hiring-guidelines) will be public.
 ## Numbering is for reference, not as a signal
@@ -399,7 +399,7 @@ Escalate to management if you are not getting the support you need. Remember tha
 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 GitLab team-members or our board member Bruce Armstrong.
+out to any of the other C-level GitLab team members or our board member Bruce Armstrong.
 ## Company Call
@@ -414,7 +414,7 @@ out to any of the other C-level GitLab team-members or our board member Bruce Ar
    * UTC: <span id="apac-UTC"></span>
    * <span id="apac-abbr"></span>: <span id="apac-USER"></span>
 1. Everyone at GitLab is invited to the company call.
-1. We also have a company call for GitLab team-members in the APAC region, which occurs every Tuesday 14:00 Australia/Sydney time.
+1. We also have a company call for GitLab team members in the APAC region, which occurs every Tuesday 14:00 Australia/Sydney time.
    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.
 1. We use [Zoom](https://gitlab.zoom.us), (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.
 1. The link is in the calendar invite and also listed at the top of the company call agenda Google Doc called _Company Call Agenda_.
@@ -511,7 +511,7 @@ Both the retrospectives and kickoffs are [live streamed](/handbook/communication
 ## Scheduling Meetings
-1. If you want to ask GitLab team-members 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.
+1. If you want to ask GitLab team members 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.
 1. 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.
 1. 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.
 1. 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
@@ -528,7 +528,7 @@ doesn't unnecessarily appear on other people's calendars.
 1. When scheduling a meeting, please try to have it start at :00 (hour) or :30 (mid-hour) to leave common start times available for other meetings on your attendees' calendars. Meetings should be for the time needed, so if you need 15 minutes just book that.
 1. When creating a calendar event that will be used company wide, please place it on the GitLab Team Meetings Calendar. That way the event is easily located by all individuals.
 1. 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.
-1. If you want to schedule a meeting with a person not on the team please use [Calendly](/handbook/tools-and-tips/#calendly). Use Google Calendar directly if scheduling with a GitLab team-member.
+1. If you want to schedule a meeting with a person not on the team please use [Calendly](/handbook/tools-and-tips/#calendly). Use Google Calendar directly if scheduling with a GitLab team member.
 ## Indicating Availability
@@ -536,7 +536,7 @@ Indicate your availability by updating your own calendar using Google's ["out of
 1. Put your planned away time including holidays, vacation, travel time, and other leave in your own calendar. Please see [Communicating your time off](/handbook/paid-time-off#communicating-your-time-off) for more.
 1. Set your working hours in your Google Calendar settings.
-1. Utilize [PTO Ninja](/handbook/paid-time-off/#pto-ninja) to keep other GitLab team-members aware of your planned time away within Slack.
+1. Utilize [PTO Ninja](/handbook/paid-time-off/#pto-ninja) to keep other GitLab team members aware of your planned time away within Slack.
 ## Video Calls
@@ -674,14 +674,14 @@ This makes the link more prominent and makes it easier to follow while viewing t
    1. When referring to a quarter in a future or past year, combine the two above: "FY21-Q1"
 1. 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.
 1. We use UTC as the timezone for engineering (for example production postmortems) and all cross-functional activities related to the monthly release. We use Pacific Time (PT) for all other uses since we are a San Francisco-based company. Please refer to time as "9:00 Pacific" or `9:00 PT`. It isn't often necessary to specify whether a timezone is currently observing Daylight Saving Time, and such references are often incorrect, so prefer "PT" to "PDT" or "PST" unless you have a specific need to differentiate between PDT and PST.
-1. Although we're a San Francisco based company we're also an internationally diverse one. Please do not refer to team-members outside the US as international, instead use non-US. Please also avoid the use of offshore/overseas to refer to non-American continents.
+1. Although we're a San Francisco based company we're also an internationally diverse one. Please do not refer to team members outside the US as international, instead use non-US. Please also avoid the use of offshore/overseas to refer to non-American continents.
 1. If you have multiple points in a comment or email, please number them. Numbered lists are easier to reference during a discussion over bulleted lists.
 1. When you reference an issue, merge request, comment, commit, page, doc, etc. and you have the URL available please paste that in.
 1. In making URLs, always prefer hyphens to underscores, and always use lowercase.
 1. 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".
-1. When we refer to the GitLab community excluding GitLab team-members please say "wider community" instead of "community".
+1. When we refer to the GitLab community excluding GitLab team members please say "wider community" instead of "community".
 1. All people working for GitLab (the company) are the [GitLab team](/company/team). We also have the [Core team](/community/core-team/) that consists of volunteers.
-1. Please always refer to GitLab Inc. people as GitLab team-members, not employees.
+1. Please always refer to GitLab Inc. people as GitLab team members, not employees.
 1. Use [inclusive and gender-neutral language](https://techwhirl.com/gender-neutral-technical-writing/) in all writing.
 1. Always write "GitLab" with "G" and "L" capitalized, even when writing "GitLab.com", except within URLs. When "gitlab.com" is part of a URL it should be lowercase.
 1. Always capitalize the names of GitLab products, [product tiers](/pricing/), and [features](/features/).