docs: Update release documentation and release GH issue template (#274)

A few changes have been made to the release process. They are now documented.

In order to make sure we don't miss any steps while releasing, I am adding a release
GH issue template. This template contains a checklist we must follow for every release.
This issue for every release can also be helpful to have conversations about every release in one place.

Author: karencfv

.github/ISSUE_TEMPLATE/BUG_REPORT.md

@@ -1,7 +1,7 @@
 ---
 name: Bug Report
 about: Create a report to help us improve.
-labels: area:tooling
+labels: area:delivery
 
 ---
 <!--- Thank you for taking the time to create a Bug Report! -->

.github/ISSUE_TEMPLATE/FEATURE_REQUEST.md

@@ -1,7 +1,7 @@
 ---
 name: Feature Request
 about: Suggest an idea for this project.
-labels: area:tooling
+labels: area:delivery
 
 ---
 <!--- Thank you for taking the time to open a Feature Request -->

.github/ISSUE_TEMPLATE/GENERIC_QUESTION.md

@@ -1,7 +1,7 @@
 ---
 name: Generic Question
 about: Not a Bug Report or a Feature Request? Ask a question.
-labels: area:tooling
+labels: area:delivery
 
 ---
 <!--- Thank you for taking the time to ask us a question! -->

.github/ISSUE_TEMPLATE/RELEASE_CHECKLIST.md

@@ -0,0 +1,23 @@
+---
+name: Release Checklist
+about: Items to be completed in every release.
+labels: area:delivery
+
+---
+<!-- Before starting the release process please make sure you've -->
+<!-- read the release documentation in /developer_docs/RELEASE.md -->
+
+## Version to be released
+<!-- Please write the version to be released. -->
+<!-- It should follow the following format: vX.Y.Z -->
+
+## Checklist
+<!-- The following actions must be performed in the order specified here. -->
+- [ ] Verify a cloud-sdk-go release with the same version has been made.
+- [ ] Update the cloud-sdk-go dependency.
+- [ ] Update `VERSION` environment variable in the Makefile and generate changelog.
+- [ ] Execute the release.
+- [ ] Create release branch for documentation.
+- [ ] Modify the conf.yaml file in the docs repository to add the release branch.
+- [ ] Run a full doc rebuild.
+- [ ] Celebrate :tada:

developer_docs/RELEASE.md

@@ -6,6 +6,12 @@ This guide aims to provide guidance on how to release new versions of the `ecctl
 
 Releasing a new version of the binary implies that there have been changes in the source code which are meant to be released for wider consumption. Before releasing a new version there's some prerequisites that have to be checked.
 
+### Verify a release in cloud-sdk-go has been made
+
+Unless this is a patch release, make sure a cloud-sdk-go release with the same version has been made.
+
+Once this is done, the cloud-sdk-go dependency should be updated to that version.
+
 ### Make sure the version is updated
 
 Since the source has changed, we need to update the current committed version to a higher version so that the release is published.
@@ -26,10 +32,24 @@ export VERSION ?= v1.1.0
 
 ### Generating a changelog for the new version
 
-Once the version is updated, we can then generate the changelog by calling `make changelog`, you can see an example changelog in [`notes/EXAMPLE.md`](../notes/EXAMPLE.md). The idea is to fill all the applicable sections so that users can consume an orderly changelog.
+Once the version is updated, we can then generate the changelog and release notes by calling `make changelog`.
 
-After a changelog has been manually curated, a new pull request can be opened with the changelog and version update changes.
+Take a look at one of our previous releases [`v1.0.0-beta2.adoc`](../docs/release_notes/v1.0.0-beta2.adoc) and the [template](../scripts/changelog.tpl.adoc) we use to generate them. The idea is to fill all the applicable sections so that users can consume easily.
+
+After the release notes have been manually curated, a new pull request can be opened with the changelog, release notes and version update changes.
 
 ## Executing the release
 
-After the new changelog and version have been merged to master, the only thing remaining is to run `make tag`. This is the makefile target which will push the GitHub tag and will trigger the corresponding [GitHub action](.github/workflows/release.yml) which will release ecctl.
+After the new changelog and version have been merged to master, the only thing remaining is to run `make release`. This is the makefile target which will push the GitHub tag and will trigger the corresponding [GitHub action](.github/workflows/release.yml) which will release ecctl.
+
+## Post release requirements
+
+After a release has been performed there are still a few things we need to do.
+
+### Create documentation specific to the release
+
+In order to have the documentation live for our new release we need to modify the conf.yaml file in the docs repository to [add the release branch](https://github.com/elastic/docs/blob/master/conf.yaml#L837) and have the build [point to our new branch](https://github.com/elastic/docs/blob/master/conf.yaml#L836).
+
+Once the PR for the above changes has been merged, you'll need to run a full doc [rebuild](https://elasticsearch-ci.elastic.co/job/elastic+docs+master+build/build?delay=0sec) to make the new release branch the default docs.
+
+![alt text](docs-rebuild.png "rebuild instructions")