Merge pull request layer5io#5887 from layer5io/release

add release managers role in handbook

src/sections/Community/Handbook/community-roles.js

@@ -223,6 +223,54 @@ const CommunityGuide = () => {
             <label htmlFor="maintainer-checklist-7">
               Understands the workflow of the Issues and Pull Requests
             </label>
+            <a id="ReleaseManager">
+              <h2>Release Manager Role</h2>
+            </a>
+
+            <p>
+              The role of release manager for a release lasts a total of about 6 months. This is divided up among activities before the initial release comes out and activities after the initial release while the release is within active maintenance. The majority of the time is spent in the month before the first release. After that, there is 6 months of time during which point releases come out on approximately a 3 week cycle. During three of these months, the release manager is working on the latest release. This 6 month time period is divided into two sections. In the first three months, this is the primary release and all fixes get cherry-picked from master here. After 3 months, the next release of the Meshery project comes out and there are three more months of support before this release goes to the end of life.
+            </p>
+
+            <h3 >Responsibilities</h3>
+
+            <h4>Before Release</h4>
+            <ul>
+              <li>Cutting branches -- 8 to 16 hours divided between all release managers. Working on automating. Will still take a while with automation, probably around half a day. With automation, a lot of the time will be waiting for automated steps to complete as opposed to being directly involved.</li>
+              <li>Testing days -- 8 to 16 hours divided between all release managers spread over two weeks in order to orchestrate the testing events. This does not include any time that the release managers additionally devote to picking up and testing individual tests.</li>
+              <li>Spreadsheets</li>
+              <li>Prioritization</li>
+              <li>Chasing people to get things done</li>
+              <li>Prioritization of issues in step with workgroups</li>
+              <li>Release management meetings -- 45 minutes to 1 hour every week for each release manager. Increases as the release gets closer.</li>
+              <li>Release notes/upgrade notes for point release -- 1 week for of the release managers as well as reviewing from other release managers</li>
+              <li>Code reviews from docs team as well as workgroup leads</li>
+              <li>Generation of release notes using automated tooling</li>
+              <li>Updating release notes to make them more readable</li>
+              <li>Announcement of release on Twitter/Discuss/Slack -- 5 minutes for one release manager for Discuss/Slack. For Twitter, reach out to someone with access.</li>
+            </ul>
+
+            <h4>Ongoing for all releases</h4>
+            <ul>
+              <li>Watching for release blockers - part of the code review process. Wouldn't say it needs additional time</li>
+              <li>Code reviews/deciding whether to accept cherry picks -- about an hour per day for each release manager. Ramps up just before the initial release. Ramps down to an hour per week towards the EOL for a release</li>
+              <li>Minor release every 3 weeks.</li>
+              <li>Release notes - 1 hour for a single release manager</li>
+              <li>Creating releases - 8 hours spread across all release managers. Most of this is automated (i.e. update proxy and then wait for tests to complete, trigger a build and wait for tests to complete)</li>
+              <li>48 hour testing -- this involves requesting those who run the tests to trigger the tests and waiting for 48 hours. There is very little needed from a release manager other than checking in to make sure everything is working well</li>
+              <li>Handle vulnerability fix integration in step with product security workgroup -- approximately 3 patch releases -- for private security releases, release managers are responsible for coordinating a flush release to get all fixes before the security fix out as well as ensuring they don't accept patches until the release is out. Most of the additional release related work is taken care of by the security fix lead although the release managers are expected to review release notes, build PRs, and other related content. The flush release takes about the same amount of time as a regular release.</li>
+              <li>Meshery build and release meetings -- one hour per release manager per week</li>
+              <li>End Of Life for release -- 8 hours</li>
+            </ul>
+
+            <h3>Qualifications for Release Manager</h3>
+            <ul>
+              <li>A member of the Layer5 community and active for the last 3 months</li>
+              <li>Approved by a majority vote of current maintainers.</li>
+              <li>At least one release manager for each version needs to meet requirements for access info in case of vulnerabilities</li>
+            </ul>
+
+            <h3>Process for volunteering for release management</h3>
+            <p>Contact a current maintainer to volunteer or nominate yourself.</p>
           </div>
           <TocPagination />
         </Container>