Add checklists + restructure instructions

[carlisia]

Closes #111.

What: This PR's big goal is to decouple these concepts:

• procedure documentation
• listing of things to be done
• sequencing of things to be done

How:

• adds 1 GH issue templates with a list of todos for the release

• adds a PROCEDURE.md file that:

  • documents relevant operations related to a release
  • includes a short version of a ToC at the top specifying the specific order in which to perform operations
  • adds an Exceptions section (for operations that have exceptions) so when going thru the instructions in order, it is clear what is to be skipped

• adds a PHASES.md TIMELINE.md file that:

  • functions as an entry point for where, when and how to get started with the release work
  • groups repos and operations for a release into separate checkpoints in the release timeline, much in the way that was in the original doc
  • includes links to only relevant sections in the (Procedure) documentation related to a particular checkpoiint

• removes the INSTRUCTIONS.md file, since the info in there has been split into the above two new files; didn't reuse the name "instructions" because both new files contain instructions, so named them more precisely to reflect the content of each.

There were a lot of minor edits to the documentation.

Minor changes worth noting:

• spruced up the README.me.
  • removed the table of repos, since they are all listed (per phase) in the PHASES.md file. If it is useful to have that unified table of repos up on the front page, I can put it back. ❓
• changed the PR used as reference to add/remove leads (in the PROCEDURES.md file) since the existing one being used didn't update the OWNERS_ALIASES file
• I don't know if the value for the assignees field in the templates will work. Using knative/knative-release-leads failed the regex validation, so I used only knative-release-leads to test. Either it will work, or be ignored.

Thanks to @nader-ziada and @psschwei for the prior improvements!

---

updated on 6/8

[psschwei]

@carlisia is this still WIP? (looking forward to giving this a go on the next release cycle!)

[carlisia]

Hey @psschwei yes, still wip, will update shortly!

[carlisia]

Pinging ppl who might be interested in reviewing this change. Please don't all feel required to review 🤓

• current @knative/knative-release-leads
• incoming release leads: @psschwei / @evankanderson
• prior release leads: @nader-ziada / @kvmware / @xtreme-sameer-vohra / @dprotaso

[psschwei]

Overall, I think this is great and will make the release process much easier going forward!

One general question: what do you think about adding direct links to the procedures from the task items? For example, when starting on the "updating the releasability defaults" task in template 2, I think it'd be nice to be able to click straight to that section rather than going through the phases doc to get there.

[evankanderson]

A few comments, but lgtm

[carlisia]

Overall, I think this is great and will make the release process much easier going forward!

One general question: what do you think about adding direct links to the procedures from the task items? For example, when starting on the "updating the releasability defaults" task in template 2, I think it'd be nice to be able to click straight to that section rather than going through the phases doc to get there.

Hm... that is how I started doing it. I decided to go this way to avoid having a bunch of links in the checklist. Having only 1 entry point to the documentation for each checklist and having it match to the corresponding phase made it feel like there is some uniform convention. And this avoids the following nightmare scenario: someone changes anything to do with the sections of that Procedures file, and now a linke broken or not as relevant. It could be hard to remember, and a pain to also have to, change it in the checklist.

[dprotaso]

adds 9 GH issue templates

My preference is to consolidate the templates into a single one.

Some advantages in my mind:

1. There would be a stable link for the entire release process - so anyone could visit that link and see the overall progress that's been made
2. More ergonomic - single issue vs. opening/closing 9 issues.

[psschwei]

scenario: someone changes anything to do with the sections of that Procedures file, and now a linke broken or not as relevant. It could be hard to remember, and a pain to also have to, change it in the checklist.

That's funny, my initial worry was the opposite, where someone changes something in the Procedures but doesn't update the issue and/or the Phases doc. If it's six in one and half dozen in the other, may as well go with the bird in hand (I thought about trying to work one more bird allusion in there, but couldn't quite bring myself to cross that road...)

My preference is to consolidate the templates into a single one.

I think I agree with Dave on this, though I don't think Github wanted me to tell you about it:

[carlisia]

This is ready for another review:

• addressed the concerns
• made changes to the doc, mainly scratching the concept of "phases" and changing that to "timeline checkpoints"
• converged all checklists into 1 checklist

I am resisting adding a bunch of links to documentation in the checklist (each pointing to corresponding sections of the PROCEDURES doc. If anything, we need those links in the TIMELINE anyway, so that would cause duplication. My suggestion: use this version for the next one or two releases, and if the leads report it'd be convenient to have those links in the checklist, then they can be added.

[carlisia]

Note: there's no instruction for how to put together a blog post for the release. I added an issue for that to be added later: Add instructions for how to put together a blog post for a new release · Issue #137 · knative/release.

[psschwei]

A couple of nits, but otherwise LGTM

[carlisia]

Thanks for the very helpful review @psschwei! I believe I hit them all.

Ready for another round.

[psschwei]

/lgtm
/approve
/hold
for others to comment

[evankanderson]

/lgtm
/approve
/hold cancel

[knative-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: carlisia, evankanderson, gabo1208, psschwei

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [evankanderson,psschwei]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment