From a7a35556be11c190fc25ab9a347bfab311f36362 Mon Sep 17 00:00:00 2001 From: Peter Nied Date: Thu, 10 Feb 2022 00:08:02 +0000 Subject: [PATCH 1/3] Adding Release owner section to maintainers Describing the intention behind being a release owner and approaches to different situations that occur during the a release. Signed-off-by: Peter Nied --- .github/ISSUE_TEMPLATE/release_template.md | 2 +- MAINTAINERS.md | 46 ++++++++++++++++++++-- 2 files changed, 44 insertions(+), 4 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/release_template.md b/.github/ISSUE_TEMPLATE/release_template.md index e168b647a0..eaa9992190 100644 --- a/.github/ISSUE_TEMPLATE/release_template.md +++ b/.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 diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 3e5c50b649..be355cadcc 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -1,15 +1,21 @@ - [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 +Release owner is a temporary role for the duration of a given OpenSearch / OpenSearch Dashboard release, it is made concrete by assigning a release ticket to them. They oversee 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, 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 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 part of the prescribed release process. For these events the release owner will determined 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 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 confirmation the correction was completed have occurred. This is overhead and undesired but important to account 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 should 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. + +The release itself needs a retrospective, generated off of an issue created during the release and filled with feedback throughout the process. A synchronous meeting has benefits to capture many ideas and get context, but it is not required. This process is not an exercise in assigning blame but accepting what happened so a remedy can be made. + +After the retro items are in a final comment should be generated 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. + From 42cad864bd165a3e2d5a07fe8639ceecf81a90c1 Mon Sep 17 00:00:00 2001 From: Peter Nied Date: Thu, 10 Feb 2022 17:51:32 +0000 Subject: [PATCH 2/3] Addressed specific feedback Signed-off-by: Peter Nied --- MAINTAINERS.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index be355cadcc..de41a186d5 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -4,9 +4,9 @@ - [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) + - [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-zenhub) @@ -35,37 +35,37 @@ [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 -Release owner is a temporary role for the duration of a given OpenSearch / OpenSearch Dashboard release, it is made concrete by assigning a release ticket to them. They oversee 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. +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, 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. +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 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. +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 part of the prescribed release process. For these events the release owner will determined the stakeholders and work with them to a resolution. +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 +### 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 +#### 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 in the root causes GitHub repository, with the release version tag and referenced in the components release issues. +- 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 +### 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 confirmation the correction was completed have occurred. This is overhead and undesired but important to account that the process was completed as expected, see an [example](https://github.com/opensearch-project/opensearch-build/issues/954). +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 should 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. +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. -The release itself needs a retrospective, generated off of an issue created during the release and filled with feedback throughout the process. A synchronous meeting has benefits to capture many ideas and get context, but it is not required. This process is not an exercise in assigning blame but accepting what happened so a remedy can be made. +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 generated 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. +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. From 8329e0fb3048036beb7d75e7bc99a2a3c09338b4 Mon Sep 17 00:00:00 2001 From: Peter Nied Date: Thu, 10 Feb 2022 18:51:14 +0000 Subject: [PATCH 3/3] Updates after reading aloud Signed-off-by: Peter Nied --- MAINTAINERS.md | 30 +++++++++++++----------------- 1 file changed, 13 insertions(+), 17 deletions(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index de41a186d5..4fd2a88c7e 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -35,37 +35,33 @@ [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. +The release owner is a temporary role for the duration of a given OpenSearch / OpenSearch Dashboards release. This owner is tracked by the assignment of a release ticket an individual. The release owner oversees the release ticket, makes sure the activities are completed, and closed the release. Release activities are documented in 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. +The release owner performs the activities described in the overall release ticket. Other activities associated with the release are managed by the component release owners or are be delegation to the most appropriate area owner. Keeping the release owner's activities well document and predicable ensures the release process avoids bottlenecks. ### 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. +Tasks will become unclear to complete, the release owner’s role is to make sure that a path to resolution is found by involving those that are needed and communicating via the primary release issue and on the component release issues. ### 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. +Create a new issue in GitHub any time the release schedule is impacted. For transparency GitHub has all the information pertaining to state of the release. #### 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. +- For issues impacting a single component, created an issue in the component’s GitHub repository, with the release version tag and referenced on the component's release issue. +- For issues impacting multiple components, create an issue in the root cause's GitHub repository, with the release version tag and referenced in the component's release issues. +- For issues impacting all / blocking any productivity, create an issue immediately in this repository, with the release version tag, and post a comment in the general release ticket. Make a broad call to action for stakeholders to engage in the issue. Closely monitor the issue until the release can resume as planned. ### Correcting Mistakes -Mistakes will happen, correcting these transparently is paramount. Use markdown strike-through when making edits to correct incorrect information instead of deleting. +Mistakes 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). +Some mistakes are larger, such as a process that was marked completed was done so incorrectly, these corrections need additional tracking as a campaign. Create an issue to drive the campaign with a list of components to track statuses such as notifications and confirmation of the correction. 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. +The release process will be improved and invested in, running a retrospective and communicating an summary of its results is necessary to achieve this. Retrospectives are encouraged at the component level in the component release issues template. -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. +Feedback comes from the retro issue created during the release and component level retrospectives. A meeting could be run to capture additional feedback if desired. This process is focused on recording what happened to make remedies. + +After the retro items are in, a final summary is written as a comment on the retrospective issue. The comment includes areas of consideration for the project alongside action items with owners to drive them, [example](https://github.com/opensearch-project/opensearch-build/issues/880) summary. ## 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.