Adding Release owner section to maintainers

.github/ISSUE_TEMPLATE/release_template.md

@@ -13,7 +13,7 @@ I noticed that a manifest was automatically created in [manifests/{{ env.VERSION
 
 ## This Release Issue
 
-This issue captures the state of the OpenSearch release, its assignee is responsible for driving the release. Please contact them or @mention them on this issue for help. There are linked issues on components of the release where individual components can be tracked.
+This issue captures the state of the OpenSearch release, its assignee is responsible for driving the release. Please contact them or @mention them on this issue for help. There are linked issues on components of the release where individual components can be tracked.  More details are included in the Maintainers [Release owner](https://github.com/opensearch-project/opensearch-build/blob/main/MAINTAINERS.md#release-owner) section.
 
 ## Release Steps
 

MAINTAINERS.md

@@ -1,15 +1,21 @@
 <img src="https://opensearch.org/assets/brand/SVG/Logo/opensearch_logo_default.svg" height="64px"/>
 
 - [Maintainers](#maintainers)
+- [Release Owner](#release-owner)
+  - [Release Activities](#release-activities)
+  - [Dealing with Ambiguity](#dealing-with-ambiguity)
+  - [Managing Critical Issues](#managing-critical-issues)
+    - [General Guidelines](#general-guidelines)
+  - [Correcting Mistakes](#correcting-mistakes)
+  - [Retrospectives](#retrospectives)
 - [ZenHub Process Workflow](#zenhub-process-workflow)
-  - [What is ZenHub](#what-is-zenhubhttpswwwzenhubcom)
-  - [Dev Deployment](#dev-deployment)
+  - [What is ZenHub?](#what-is-zenhub)
   - [Setting up ZenHub](#setting-up-zenhub)
   - [Sprint Board](#sprint-board)
     - [Pipelines](#pipelines)
   - [Creating Issues](#creating-issues)
   - [Managing issues/stories](#managing-issuesstories)
-  - [Spillovers](#spillovers)
+    - [Spillovers](#spillovers)
   - [Epics](#epics)
   - [Recurring Team Meetings](#recurring-team-meetings)
   - [On-Call](#on-call)
@@ -28,6 +34,39 @@
 
 [This document](https://github.com/opensearch-project/.github/blob/main/MAINTAINERS.md) explains what maintainers do in this repo, and how they should be doing it. If you're interested in contributing, see [CONTRIBUTING](CONTRIBUTING.md).
 
+## Release Owner
+The release owner is a temporary role for the duration of a given OpenSearch / OpenSearch Dashboards release.  This owner is tracked by assigning a release ticket to the individual taking on this responsibility.  The release owner oversees the release ticket and make sure that it completes.  While tactical release actions should always be a part of the release ticket, see the [template](./.github/ISSUE_TEMPLATE/release_template.md). The purpose of the Release owner is to be responsible for following the release process.
+
+### Release Activities
+There are many activities associated with the release, and the release owner should not be a bottleneck to accomplish those tasks - to prevent this they should only be performing the tactical actions described in the release ticket.
+
+Component teams need to balance the execution of their own release activities.  This includes running tests or reviewing PRs or filling in for the functions of that team.  The release owner does not need to know the quality requirements and considerations for each component - they should not be expected to enforce or bypass them.
+
+### Dealing with Ambiguity 
+There will be release tasks that do not have a clear path for completion, the release owner role is to make sure that a path can be found by involving those that are needed and communicating that out via the primary release issue and on the component release issues.
+
+Sometimes ambiguity will arise if deadlines are missed - what the result will be to the release, or an exception request from a component to a part of the prescribed release process. For these events the release owner will determine the stakeholders and work with them to a resolution.
+
+### Managing Critical Issues
+GitHub should have as much information as is possible to have for what the current state of the release is and the items that are being tracked for it.  When something occurs that can impact a release an issue should always be created so there is an independent tracking mechanism.
+
+#### General Guidelines
+- For issues only impacting a single component, those should be created in that components GitHub repository, with the release version tag and referenced on the component release issue.
+- For issues impacting multiple components, it should be created in the root causes GitHub repository, with the release version tag and referenced in the components release issues.
+- For issues impacting all / blocking any productivity, those should be created as quickly as possible in this repository, with the release version tag, and referenced in the general release ticket.  As soon as this is done, there should be a call to action from the stakeholders to make sure it is addressed and resolved as soon as possible.
+
+### Correcting Mistakes
+Mistakes will happen, correcting these transparently is paramount.  Use markdown strike-through when making edits to correct incorrect information instead of deleting.
+
+Some mistakes will be larger, such as a process that was thought was completed, was not completed or invalidated.  Create an issue to track and drive it as a campaign, making sure that notifications and confirmations the correction was completed have occurred.  This is important to confirm that the process was completed as expected, see an [example](https://github.com/opensearch-project/opensearch-build/issues/954).
+
+### Retrospectives
+There will be things that can be improved and invested in, running a retrospective and communicating the synthesis of its results is necessary to achieve this.  Retrospectives are always encouraged at the component level.
+
+Feedback will primarily come from the retro issue created during the release and component level retrospectives.  A synchronous meeting has benefits to capture many ideas and get additional context, but it is not required.  Note, this process is not an exercise in assigning blame but recording what happened so a remedy can be made.
+
+After the retro items are in a final comment should be written that includes important areas of consideration for the project and the action items with owners to drive them, [example](https://github.com/opensearch-project/opensearch-build/issues/880) with reflection. 
+
 ## ZenHub Process Workflow
 We follow agile methodologies for our development and release process. We use GitHub issues with annotations via ZenHub to manage and track our stories and issues to effectively manage them over the sprint.
 
@@ -115,3 +154,4 @@ This would ensure that all the tasks the an individual is working on is correctl
 
 ### On-Call
 Since on-call is a weekly rotation, we do not create an issue for on-call. However, if on-call requires you to work on a bug, please make sure that we have issue associated with the task for tracking.
+