Replace references to release guild with releases team (#8891)

* Replace slack channel references to discuss-release-ship with
discuss-releases
* Fix github team label for the releases team
* Replace references to release guild with the releases team

content/company-info-and-process/communication/team_chat.md

@@ -533,7 +533,7 @@ There’s no one-size-fits-all approach here. Just be mindful of the frequency o
    </td>
   </tr>
   <tr>
-   <td>#discuss-release-ship
+   <td>#discuss-releases
    </td>
    <td>People who have questions and updates about releases
    </td>

content/departments/engineering/dev/process/releases/procedure.md

@@ -4,7 +4,7 @@
 
 The goal of code freeze is to stabilize the release for the final build, and to mitigate risk with each change by fixing bugs caught during the QA process, or making improvements that increase stability and quality in the final build.
 
-During the code freeze we will typically cut a new candidate each day and deploy it to the test instance for additional QA. If additional candidates are necessary, reach out to the release guild.
+During the code freeze we will typically cut a new candidate each day and deploy it to the test instance for additional QA. If additional candidates are necessary, reach out to the releases team.
 
 There are 3 distinct sections of code freeze:
 
@@ -18,7 +18,7 @@ During open code freeze, the release branch is open to changes and will require
 
 ### Closed code freeze
 
-A few days before the release the branch will be closed to changes and will require a member of the release guild to merge backports. The goal of this step is to stabalize a final build. During this period release captains will exercise discretion whether a change warrants backport. Some guidelines for things that are eligible:
+A few days before the release the branch will be closed to changes and will require a member of the releases team to merge backports. The goal of this step is to stabalize a final build. During this period release captains will exercise discretion whether a change warrants backport. Some guidelines for things that are eligible:
 
 1. Documentation
 2. Bug fixes
@@ -42,15 +42,15 @@ For a quarterly release, a recommended schedule looks like this:
 2. Closed freeze 2-3 days before release
 3. Final build freeze 1 day before release
 
-### Release guild responsibilities
+### Releases team responsibilities
 
-The release guild is responsible for monitoring and ensuring the release branch is healthy for the duration of code freeze. This may require some manual intervention to resolve minor issues on the branch, such as lint or running go generate.
+The releases team is responsible for monitoring and ensuring the release branch is healthy for the duration of code freeze. This may require some manual intervention to resolve minor issues on the branch, such as lint or running go generate.
 
 The release captain is responsible for orchestrating and directing as necessary anything required to achieve the outcome of a stable release at the end of code freeze. In general the release captain should be the individual to monitor and keep the release branch healthy, but may need to delegate tasks to others during unavailable days and hours.
 
 The release captain for a feature release should assume a substantial amount of their time will be allocated to managing the release and should not plan to be involved in last minute work included in the release.
 
-In general, the release guild will strive to ensure release responsibilities don't interfere with PTO and other OOO requirements for release captains by finding backup captains as necessary. However, it **is the responsibility** of the captain to ensure there is a backup captain available for any extended periods of unavailability, even if this requires reaching out to the wider engineering group.
+In general, the releases team will strive to ensure release responsibilities don't interfere with PTO and other OOO requirements for release captains by finding backup captains as necessary. However, it **is the responsibility** of the captain to ensure there is a backup captain available for any extended periods of unavailability, even if this requires reaching out to the wider engineering group.
 
 #### Common release tasks
 

content/departments/engineering/teams/release/index.md

@@ -26,15 +26,15 @@ For more detailed information on the Release team members, check out our [README
 ## Contact
 
 - #discuss-releases, or `@release-team` in Slack. Please follow our [support guidelines](#support-request-guidelines) below.
-- [team/release](https://github.com/sourcegraph/sourcegraph/labels/team%2Frelease-ship) label and [@sourcegraph/release](https://github.com/orgs/sourcegraph/teams/release) team on GitHub.
+- [team/release](https://github.com/sourcegraph/sourcegraph/labels/team%2Frelease) label and [@sourcegraph/release](https://github.com/orgs/sourcegraph/teams/release) team on GitHub.
 
 ## Support
 
 If in doubt about the process, please ask in #discuss-releases. Teammates should consult our [support-rotation](./processes.md#support-rotation) guide to handle inquiries.
 
 ### Requesting our support
 
-Feel free to direct simple questions to us in #discuss-release-ship in Slack. As a rule of thumb, anything that is not documented in our handbook or [docs](https://sourcegraph.com/docs) usually indicates it is not a simple question (e.g. feature requests) and should follow our [support request guidelines](./#support-request-guidelines) below.
+Feel free to direct simple questions to us in #discuss-releases in Slack. As a rule of thumb, anything that is not documented in our handbook or [docs](https://sourcegraph.com/docs) usually indicates it is not a simple question (e.g. feature requests) and should follow our [support request guidelines](./#support-request-guidelines) below.
 
 - This channel _is_ regularly checked and well-monitored
 - So please do **NOT** directly message or CC an engineer—this is to try and protect their focus

content/departments/technical-success/support/process/engaging-other-teams.md

@@ -205,7 +205,7 @@ After you file a GitHub issue, keep it simple and always provide;
 
 3.  the context around timeline (for example: it's okay to look at this tomorrow or later in the week).
 
-- When posting in Release team's channel, [#discuss-release-ship](https://sourcegraph.slack.com/archives/C02E4HE42BX), use @release-team
+- When posting in Release team's channel, [#discuss-releases](https://sourcegraph.slack.com/archives/C02E4HE42BX), use @release-team
 - When posting regarding a Batch Changes issue, post in [#discuss-code-search](https://sourcegraph.slack.com/archives/C05EA9KQUTA), use @batcher-support
 - When posting for Repository Management, be sure to do so in the [#discuss-source](https://sourcegraph.slack.com/archives/C05EMJM2SLR) channel and use @source-support
 - When posting for Cloud, be sure to do so in the [#discuss-cloud-ops](https://sourcegraph.slack.com/archives/C03JR7S7KRP) channel and use @cloud-support

data/glossary.yml

@@ -193,7 +193,7 @@ role:
     definition: Purchase order
   - term: IC
     definition: Individual contributor, not managing other people. Still works on a team with other ICs.
-  - term: Release Guild
+  - term: Releases team (formerly Release Guild)
     definition: A captain of releasing the product, drives releases, gathers and informs others about the release, helps test the release, fixes and discovers issues in the release before it goes out.
   - term: DevRel
     definition: Developer relations, they post on Hacker News, Reddit, and Twitter about how cool we are. They give talks and go to conferences

data/guilds.yml

@@ -1,14 +1 @@
-release_guild:
-  title: Release Guild
-  leader: bolaji_olajide
-  leadership_sponsors: [quinn_slack]
-  members:
-    [
-      joe_chen,
-      camden_cheek,
-      keegan_carruthers-smith,
-      mohammad_umer_alam,
-      bolaji_olajide,
-      warren_gifford,
-      jacob_pleiness,
-    ]
+{}