From 6321b893c62ee55b81b237ef0c24d27ca2992841 Mon Sep 17 00:00:00 2001 From: tursynay <65674466+tursynay@users.noreply.github.com> Date: Thu, 9 Nov 2023 09:15:54 -0800 Subject: [PATCH 1/7] Create Translator Release Process Details --- Translator Release Process Details | 75 ++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 Translator Release Process Details diff --git a/Translator Release Process Details b/Translator Release Process Details new file mode 100644 index 0000000..7369c1f --- /dev/null +++ b/Translator Release Process Details @@ -0,0 +1,75 @@ +Translator Release Process Details + +The proposed “release process” is just three simple phases: +Code Window +Freeze and Prep Window +Retrospective + +Code window (2 months): +GOAL: To establish a predictable schedule for deployment requests, coordinate deployments between interdependent components, and help improve our various teams’ ability to plan ahead. +Definition: Do good work and keep in touch. + +Freeze-and-prep window (1 month): +GOAL: To come together as a unified consortia to coordinate agendas between our working groups and committees, be transparent about when work is coming for different teams, give testers the ability to see what they should be testing with priority for a release, and try to reduce the “pre-relay scramble.” +Definition: Finalize the Release to PROD (testing) and Plan the next release (TACT) +Current Release Finalization +Manual SMuRF (Subject Matter Reasonably Familiar) / SME (Subject Matter Expert) testing on TEST of new component(s) or extensive updates to existing components that were approved during the prior release planning cycle. Testing may also reveal bugs not related to the deployed code and/or can identify new feature requests. +The SMuRF coordinator should be able to tell from the milestones identified for the release, what the major areas of work should be tested for the release, what components or MVPs or displays need to be tested/confirmed in TEST. +Note: when more automated tests are in place, we can re-evaluate the kinds of manual testing required. +SMuRF coordinator might want to keep a simple list of manual tests that are helpful to confirm every release. +TAQA will meet each week to help triage resulting issues back to teams, request feedback from the group about what constitutes a bug that must be fixed before release, and also keep track of new issues/features for prioritization in the next release. +TACT decides on a case-by-case basis if production deployment is go/no-go for new component(s) +TACT votes via procedures outlined in the current Consortium Guidelines - see Change Management section here +Subsequent Release Planning +Team/Working Group/Committee/External Group bring proposal(s) for new component(s) or extensive updates to existing component(s) to TACT for review +Teams to include the following details: +Theme (required) +e.g. what working group, committee, architecture component this task belongs to. +Milestone: a short, executive summary of the proposed work. (required) +e.g. - Fix Biolink Documentation: Deliver a refactored repository following LinkML best practices with documentation that is searchable and navigable as it previously was. +e.g. - Host a series of discussions around modeling “variants” for use in Translator: At the end of the cycle, propose options to the Data Modeling team for confirmation. +e.g. - Revisit SRI confidence score [g() function]: deploy a revised scoring algorithm that takes SRI confidence score into account. +Specific steps to accomplish the milestone (or a link to a GitHub project tracker) (required) +Timeline for completing the proposed work for completing the proposed work +Responsible teams (or individuals) (required) +Status (optional) +Any additional notes that help clarify the tasks represented by the deliverable (optional) +e.g. - will this involved release coordination with any other teams? +e.g. - will the release of this component mean work for another team next release? +Example: winter 2023/4 release milestones reviewed by TACT +TACT defines the work units required for production deployment of the proposed component(s) as part of the next release. + +Review process, revise if necessary, and repeat as part of next release +GOAL: formalize the need to not institutionalize processes that make production of Translator components unnecessarily difficult, slow, confusing, or monotonous. +Retrospective participants should feel comfortable expressing their successes and challenges in the context of the release, bringing with them specific examples (when possible) of things that were good or bad, preferably with suggestions on how to make the process better. +Hotfixes +GOAL: Allow changes to go into PROD during the coding window when they address critical errors in the deployed feature. +Definition: a hotfix is a code change to address a bug that is deployed between official release cycles. Hotfixes do not address non-critical issues, new features, or incremental improvements and optimizations. +Policy: Teams can propose hotfixes to be reviewed and approved by TACT +TACT members making hotfix decisions, will greatly benefit from hotfix descriptions following a basic template: +Sample Changelog for Code Window deployments to PROD +sample changelog for PROD deployment request - ARAX + +Translator Release Schedule Timeline +Translator Release Process Guidelines + + +Nomenclature: +Code Window - develop the priorities set for the window +Deliverables: +Accomplish the goals set up in the Freeze/Slush and Prep Window. +Changelog and request to ITRB to move to TEST in the first week of the Freeze/Slush Prep Window. +Per Release Guidelines, during the two month code window and freeze-and-prep period, no releases to Prod will be scheduled. Exceptions: UI and hotfixes. +Freeze/Slush and Prep Window +TAQA - test, triage, retest +Two weeks of iteration on CI +Two pushes (push request due on Friday before) to TEST on Tuesdays +Deliverables: +Weekly pushes to TEST with changelog +Fully tested code +TACT - set priorities for the next coding window +Deliverables: +Host WGs and Committees to discuss next-release cycle priorities +The next release cycle plan +A process retrospective: host a 15-minute review of the process, how it worked, and what could be improved +Release to PROD! From 175256c4b19cb4c3f8dfc3a57d2ae2d0e5433d3e Mon Sep 17 00:00:00 2001 From: tursynay <65674466+tursynay@users.noreply.github.com> Date: Tue, 21 Nov 2023 11:08:49 -0800 Subject: [PATCH 2/7] Update Translator Release Process Details Co-authored-by: Nomi Harris --- Translator Release Process Details | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Translator Release Process Details b/Translator Release Process Details index 7369c1f..7ba505f 100644 --- a/Translator Release Process Details +++ b/Translator Release Process Details @@ -10,7 +10,7 @@ GOAL: To establish a predictable schedule for deployment requests, coordinate de Definition: Do good work and keep in touch. Freeze-and-prep window (1 month): -GOAL: To come together as a unified consortia to coordinate agendas between our working groups and committees, be transparent about when work is coming for different teams, give testers the ability to see what they should be testing with priority for a release, and try to reduce the “pre-relay scramble.” +GOAL: To come together as a unified consortium to coordinate agendas between our working groups and committees, be transparent about when work is coming for different teams, give testers the ability to see what they should be testing with priority for a release, and try to reduce the “pre-relay scramble.” Definition: Finalize the Release to PROD (testing) and Plan the next release (TACT) Current Release Finalization Manual SMuRF (Subject Matter Reasonably Familiar) / SME (Subject Matter Expert) testing on TEST of new component(s) or extensive updates to existing components that were approved during the prior release planning cycle. Testing may also reveal bugs not related to the deployed code and/or can identify new feature requests. From fc9808842d3b6a98eba0d236311fe5dd1b598379 Mon Sep 17 00:00:00 2001 From: tursynay <65674466+tursynay@users.noreply.github.com> Date: Tue, 21 Nov 2023 11:08:58 -0800 Subject: [PATCH 3/7] Update Translator Release Process Details Co-authored-by: Nomi Harris --- Translator Release Process Details | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Translator Release Process Details b/Translator Release Process Details index 7ba505f..4ab077b 100644 --- a/Translator Release Process Details +++ b/Translator Release Process Details @@ -22,7 +22,7 @@ TACT decides on a case-by-case basis if production deployment is go/no-go for ne TACT votes via procedures outlined in the current Consortium Guidelines - see Change Management section here Subsequent Release Planning Team/Working Group/Committee/External Group bring proposal(s) for new component(s) or extensive updates to existing component(s) to TACT for review -Teams to include the following details: +The following details should be included in these proposals: Theme (required) e.g. what working group, committee, architecture component this task belongs to. Milestone: a short, executive summary of the proposed work. (required) From fc29841182d048c3c3ba6a020e0259073cab927b Mon Sep 17 00:00:00 2001 From: tursynay <65674466+tursynay@users.noreply.github.com> Date: Tue, 21 Nov 2023 11:09:04 -0800 Subject: [PATCH 4/7] Update Translator Release Process Details Co-authored-by: Nomi Harris --- Translator Release Process Details | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Translator Release Process Details b/Translator Release Process Details index 4ab077b..ab33f35 100644 --- a/Translator Release Process Details +++ b/Translator Release Process Details @@ -30,7 +30,7 @@ e.g. - Fix Biolink Documentation: Deliver a refactored repository following Link e.g. - Host a series of discussions around modeling “variants” for use in Translator: At the end of the cycle, propose options to the Data Modeling team for confirmation. e.g. - Revisit SRI confidence score [g() function]: deploy a revised scoring algorithm that takes SRI confidence score into account. Specific steps to accomplish the milestone (or a link to a GitHub project tracker) (required) -Timeline for completing the proposed work for completing the proposed work +Timeline for completing the proposed work Responsible teams (or individuals) (required) Status (optional) Any additional notes that help clarify the tasks represented by the deliverable (optional) From 86b39c372bacf5d7ddd40e1b6c7dbb1c66db01b7 Mon Sep 17 00:00:00 2001 From: tursynay <65674466+tursynay@users.noreply.github.com> Date: Tue, 21 Nov 2023 11:09:12 -0800 Subject: [PATCH 5/7] Update Translator Release Process Details Co-authored-by: Nomi Harris --- Translator Release Process Details | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Translator Release Process Details b/Translator Release Process Details index ab33f35..d4a548d 100644 --- a/Translator Release Process Details +++ b/Translator Release Process Details @@ -34,7 +34,7 @@ Timeline for completing the proposed work Responsible teams (or individuals) (required) Status (optional) Any additional notes that help clarify the tasks represented by the deliverable (optional) -e.g. - will this involved release coordination with any other teams? +e.g. - will this involve release coordination with any other teams? e.g. - will the release of this component mean work for another team next release? Example: winter 2023/4 release milestones reviewed by TACT TACT defines the work units required for production deployment of the proposed component(s) as part of the next release. From b59fa6e07ddf0ed07c373097020e71066633cd1c Mon Sep 17 00:00:00 2001 From: tursynay <65674466+tursynay@users.noreply.github.com> Date: Tue, 21 Nov 2023 11:39:59 -0800 Subject: [PATCH 6/7] Rename Translator Release Process Details to Translator Release Process Details.md --- ...lease Process Details => Translator Release Process Details.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename Translator Release Process Details => Translator Release Process Details.md (100%) diff --git a/Translator Release Process Details b/Translator Release Process Details.md similarity index 100% rename from Translator Release Process Details rename to Translator Release Process Details.md From 3fe47c3fa498e0fc3480174407dc2dc8fd270b85 Mon Sep 17 00:00:00 2001 From: tursynay <65674466+tursynay@users.noreply.github.com> Date: Tue, 21 Nov 2023 14:05:42 -0800 Subject: [PATCH 7/7] Update Translator Release Process Details.md formatting --- Translator Release Process Details.md | 133 +++++++++++++------------- 1 file changed, 66 insertions(+), 67 deletions(-) diff --git a/Translator Release Process Details.md b/Translator Release Process Details.md index d4a548d..df762de 100644 --- a/Translator Release Process Details.md +++ b/Translator Release Process Details.md @@ -1,75 +1,74 @@ -Translator Release Process Details +# Translator Release Process Details The proposed “release process” is just three simple phases: -Code Window -Freeze and Prep Window -Retrospective +* **Code Window** +* **Freeze and Prep Window** +* **Retrospective** -Code window (2 months): -GOAL: To establish a predictable schedule for deployment requests, coordinate deployments between interdependent components, and help improve our various teams’ ability to plan ahead. -Definition: Do good work and keep in touch. +## I. Code window (2 months): +* **GOAL:** To establish a predictable schedule for deployment requests, coordinate deployments between interdependent components, and help improve our various teams’ ability to plan ahead. + * **Definition:** Do good work and keep in touch. -Freeze-and-prep window (1 month): -GOAL: To come together as a unified consortium to coordinate agendas between our working groups and committees, be transparent about when work is coming for different teams, give testers the ability to see what they should be testing with priority for a release, and try to reduce the “pre-relay scramble.” -Definition: Finalize the Release to PROD (testing) and Plan the next release (TACT) -Current Release Finalization -Manual SMuRF (Subject Matter Reasonably Familiar) / SME (Subject Matter Expert) testing on TEST of new component(s) or extensive updates to existing components that were approved during the prior release planning cycle. Testing may also reveal bugs not related to the deployed code and/or can identify new feature requests. -The SMuRF coordinator should be able to tell from the milestones identified for the release, what the major areas of work should be tested for the release, what components or MVPs or displays need to be tested/confirmed in TEST. -Note: when more automated tests are in place, we can re-evaluate the kinds of manual testing required. -SMuRF coordinator might want to keep a simple list of manual tests that are helpful to confirm every release. -TAQA will meet each week to help triage resulting issues back to teams, request feedback from the group about what constitutes a bug that must be fixed before release, and also keep track of new issues/features for prioritization in the next release. -TACT decides on a case-by-case basis if production deployment is go/no-go for new component(s) -TACT votes via procedures outlined in the current Consortium Guidelines - see Change Management section here -Subsequent Release Planning -Team/Working Group/Committee/External Group bring proposal(s) for new component(s) or extensive updates to existing component(s) to TACT for review -The following details should be included in these proposals: -Theme (required) -e.g. what working group, committee, architecture component this task belongs to. -Milestone: a short, executive summary of the proposed work. (required) -e.g. - Fix Biolink Documentation: Deliver a refactored repository following LinkML best practices with documentation that is searchable and navigable as it previously was. -e.g. - Host a series of discussions around modeling “variants” for use in Translator: At the end of the cycle, propose options to the Data Modeling team for confirmation. -e.g. - Revisit SRI confidence score [g() function]: deploy a revised scoring algorithm that takes SRI confidence score into account. -Specific steps to accomplish the milestone (or a link to a GitHub project tracker) (required) -Timeline for completing the proposed work -Responsible teams (or individuals) (required) -Status (optional) -Any additional notes that help clarify the tasks represented by the deliverable (optional) -e.g. - will this involve release coordination with any other teams? -e.g. - will the release of this component mean work for another team next release? -Example: winter 2023/4 release milestones reviewed by TACT -TACT defines the work units required for production deployment of the proposed component(s) as part of the next release. +## II. Freeze-and-prep window (1 month): +* **GOAL:** To come together as a unified consortium to coordinate agendas between our working groups and committees, be transparent about when work is coming for different teams, give testers the ability to see what they should be testing with priority for a release, and try to reduce the “pre-relay scramble.” + * **Definition:** Finalize the Release to PROD (testing) and Plan the next release (TACT) +* **Current Release Finalization** + * Manual SMuRF (Subject Matter Reasonably Familiar) / SME (Subject Matter Expert) testing on TEST of new component(s) or extensive updates to existing components that were approved during the prior release planning cycle. Testing may also reveal bugs not related to the deployed code and/or can identify new feature requests. + * The SMuRF coordinator should be able to tell from the milestones identified for the release, what the major areas of work should be tested for the release, what components or MVPs or displays need to be tested/confirmed in TEST. + * Note: when more automated tests are in place, we can re-evaluate the kinds of manual testing required. + * SMuRF coordinator might want to keep a simple list of manual tests that are helpful to confirm every release. + * TAQA will meet each week to help triage resulting issues back to teams, request feedback from the group about what constitutes a bug that must be fixed before release, and also keep track of new issues/features for prioritization in the next release. + * TACT decides on a case-by-case basis if production deployment is go/no-go for new component(s) + * TACT votes via procedures outlined in the current Consortium Guidelines - see Change Management section here +* **Subsequent Release Planning** + * Team/Working Group/Committee/External Group bring proposal(s) for new component(s) or extensive updates to existing component(s) to TACT for review. The following details should be included in these proposals: + * **Theme (required)** + * e.g. what working group, committee, architecture component this task belongs to. + * **Milestone:** a short, executive summary of the proposed work. (required) + * e.g. - Fix Biolink Documentation: Deliver a refactored repository following LinkML best practices with documentation that is searchable and navigable as it previously was. + * e.g. - Host a series of discussions around modeling “variants” for use in Translator: At the end of the cycle, propose options to the Data Modeling team for confirmation. + * e.g. - Revisit SRI confidence score [g() function]: deploy a revised scoring algorithm that takes SRI confidence score into account. + * **Specific steps to accomplish the milestone** (or a link to a GitHub project tracker) (required) + * **Timeline** for completing the proposed work + * **Responsible teams** (or individuals) (required) + * **Status** (optional) + * Any additional **notes** that help clarify the tasks represented by the deliverable (optional) + * e.g. - will this involve release coordination with any other teams? + * e.g. - will the release of this component mean work for another team next release? + * **Example:** winter 2023/4 release milestones reviewed by TACT + * TACT defines the work units required for production deployment of the proposed component(s) as part of the next release. -Review process, revise if necessary, and repeat as part of next release -GOAL: formalize the need to not institutionalize processes that make production of Translator components unnecessarily difficult, slow, confusing, or monotonous. -Retrospective participants should feel comfortable expressing their successes and challenges in the context of the release, bringing with them specific examples (when possible) of things that were good or bad, preferably with suggestions on how to make the process better. -Hotfixes -GOAL: Allow changes to go into PROD during the coding window when they address critical errors in the deployed feature. -Definition: a hotfix is a code change to address a bug that is deployed between official release cycles. Hotfixes do not address non-critical issues, new features, or incremental improvements and optimizations. -Policy: Teams can propose hotfixes to be reviewed and approved by TACT -TACT members making hotfix decisions, will greatly benefit from hotfix descriptions following a basic template: -Sample Changelog for Code Window deployments to PROD -sample changelog for PROD deployment request - ARAX +## III. Review process, revise if necessary, and repeat as part of next release + * **GOAL:** formalize the need to not institutionalize processes that make production of Translator components unnecessarily difficult, slow, confusing, or monotonous. + * Retrospective participants should feel comfortable expressing their successes and challenges in the context of the release, bringing with them specific examples (when possible) of things that were good or bad, preferably with suggestions on how to make the process better. -Translator Release Schedule Timeline -Translator Release Process Guidelines +## IV. Hotfixes +* **GOAL:** Allow changes to go into PROD during the coding window when they address critical errors in the deployed feature. +* **Definition:** a hotfix is a code change to address a bug that is deployed between official release cycles. Hotfixes do not address non-critical issues, new features, or incremental improvements and optimizations. +* **Policy:** Teams can propose hotfixes to be reviewed and approved by TACT + * TACT members making hotfix decisions, will greatly benefit from hotfix descriptions following a basic template: + * [Sample Changelog for Code Window deployments to PROD](https://docs.google.com/document/d/1v9qT8g8CUIuvSq2JMNRYDZcvhYLQuV9QhOLmcl4ne7Y/edit#heading=h.cm9drbbgry6a) + * [sample changelog for PROD deployment request - ARAX](https://docs.google.com/document/d/1YYqasU0bcrEmxBM6yHBa0Z_4Enq8UcCifgMb4KVu7MQ/edit#heading=h.cm9drbbgry6a) +[Translator Release Schedule Timeline](https://docs.google.com/spreadsheets/d/1zU0I1upEZrdFavjHT9rRYofy7FaZp-MNGCoUkhYp5Ig/edit?usp=sharing) +[Translator Release Process Guidelines](https://docs.google.com/document/d/1h4_UKf4gwnOMFyAYPM7WajZ43NHgHZX93eHHK3pzMtU/edit?usp=sharing) -Nomenclature: -Code Window - develop the priorities set for the window -Deliverables: -Accomplish the goals set up in the Freeze/Slush and Prep Window. -Changelog and request to ITRB to move to TEST in the first week of the Freeze/Slush Prep Window. -Per Release Guidelines, during the two month code window and freeze-and-prep period, no releases to Prod will be scheduled. Exceptions: UI and hotfixes. -Freeze/Slush and Prep Window -TAQA - test, triage, retest -Two weeks of iteration on CI -Two pushes (push request due on Friday before) to TEST on Tuesdays -Deliverables: -Weekly pushes to TEST with changelog -Fully tested code -TACT - set priorities for the next coding window -Deliverables: -Host WGs and Committees to discuss next-release cycle priorities -The next release cycle plan -A process retrospective: host a 15-minute review of the process, how it worked, and what could be improved -Release to PROD! +**Nomenclature:** +* **Code Window** - develop the priorities set for the window + * _Deliverables:_ + * Accomplish the goals set up in the Freeze/Slush and Prep Window. + * Changelog and request to ITRB to move to TEST in the first week of the Freeze/Slush Prep Window. + * Per Release Guidelines, during the two month code window and freeze-and-prep period, no releases to Prod will be scheduled. Exceptions: UI and hotfixes. +* **Freeze/Slush and Prep Window** + * TAQA - test, triage, retest + * Two weeks of iteration on CI + * Two pushes (push request due on Friday before) to TEST on Tuesdays + * _Deliverables:_ + * Weekly pushes to TEST with changelog + * Fully tested code + * TACT - set priorities for the next coding window + * _Deliverables:_ + * Host WGs and Committees to discuss next-release cycle priorities + * The next release cycle plan + * A process retrospective: host a 15-minute review of the process, how it worked, and what could be improved +* **Release to PROD!**