Create Translator Release Guidelines

Translator Release Guidelines.md

@@ -0,0 +1,11 @@
+## Translator Release Guidelines
+The purpose of this document is to establish Guidelines for the Translator Release Process, the overall goal of which is to establish a predictable schedule for deployment requests, coordinate deployments between interdependent components, and create a process whereby decisions are made in advance of deployments and new Translator releases.
+
+The Translator Release Process will comprise three main phases: a two-month code window; a one-month freeze-and-prep window; and a one-week retrospective review and reevaluation window.
+* The purpose of the two-month code window is to complete the development and preliminary testing required to achieve the goals and milestones established during the prior freeze-and-prep window. Teams, working groups, and committees will largely work independently but remain coordinated via regular report outs and agenda (re)setting during meetings of the Translator Agenda Coordination Team (TACT). During the code window, Translator team members will push hotfixes (defined below) to the TEST environment, with more extensive changes to the CI environment. A final push to the PROD environment will take place at the end of the code window. The TEST environment will therefore serve as a “copy” of the PROD environment.
+* The purpose of the one-month freeze-and-prep window is two-fold: (1) finalize the current cycle’s Translator release; and (2) plan for the next cycle’s Translator release.
+   * For current release finalization, testers from within the Translator Consortium and external to it will engage in testing within the TEST environment of new component(s) or extensive updates to existing components that were approved during the prior release planning cycle. The Translator Answer Quality Analysis team (TAQA) will meet each week during the freeze-and-prep window to triage any issues that were identified as part of the testing process, request feedback from the group about what constitutes a bug that must be fixed before release (i.e., a hotfix), and track new issues and/or features for prioritization during the next release cycle. TACT will also meet each week during the freeze-and-prep window to decide on a case-by-case basis if production deployment is go/no-go for new component(s) and to plan for the next release cycle (see below). All decisions that are made by TACT will be by way of a formal vote, following the procedures outlined in the Translator Consortium Guidelines (see Change Management).
+   * For subsequent release planning, Translator teams, working groups, and committees, or external groups, will bring proposal(s) for new Translator component(s) or extensive updates to existing component(s) to TACT for review. All proposals will follow a template, including: a theme or Translator component for which the proposed work aligns; the responsible party; a short summary of the proposed work; the specific milestones required to achieve the overall goal of the proposed work; and a timeline for completing the proposed work. TACT will decide on a case-by-case basis whether the proposed work will be incorporated into the next Translator release. All decisions that are made by TACT will be by way of a formal vote.
+* The purpose of the one-week retrospective review and reevaluation window is to review the previous cycle’s release process. This window will allow Translator teams and team members to express their successes and challenges in the context of the prior release, with specific examples provided and suggestions for how to improve the process. Based on this input, TACT will decide whether or not the release process needs to be revised, and, if so, what the revised release process will look like. All decisions that are made by TACT will be by way of a formal vote.
+
+The Translator Release Process will address hotfixes on a case-by-case basis. A hotfix is defined as 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. The goal of resolving hotfixes is to allow changes to go into the PROD environment during the coding window if and only if they address critical errors in the deployed feature. Proposals for hotfixes will follow a template, including a brief description of the breaking feature, the fix, and the testing that has been conducted in the DEV environment. TACT will decide on a case-by-case basis whether the proposed work will be incorporated prior to the next official Translator release. All decisions that are made by TACT will be by way of a formal vote.