Add issue template for Gutenberg and or CoBlocks upgrade process checklist

[fullofcaffeine]

What

Adds a new template for the GitHub tracking issue, which is part of the process for upgrading Gutenberg and or CoBlocks on wpcom and its variations.

I encourage you to suggest changes/ improvements as well. I based it off an existing tracking issue with only minimal changes. I also left the short IDs as is as examples.

Todo

• Remove duplicate md file and trailing whitespace in the name and filename. I used the GitHub UI for templates to add the issue template, and for some reason GitHub added a duplicate file and the space after the name (the last one probably my fault). Fixed.
• Team Calypso review and acceptance. It seems Issues were not being used before, so this PR would introduce the first template :)
• Squash and merge 🚀

---

More about GitHub issue templates: https://help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates

[matticbot]

Test live: https://calypso.live/?branch=add/issue-template-for-gb-cb-upgrade-issue-tracking

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[noahtallen]

should they be un-checked by default? (not sure if the template works differently :p)

[fullofcaffeine]

Ah no, sorry, they should be!

[fullofcaffeine]

Let me know if you think any steps should be added/removed. The idea is not to be a one-size-fits-all, but more of an initial structure that can be used to bootstrap the issue, as some updates might require us to add new steps or more text, etc. Not all updates will be equal, I guess.

[noahtallen]

just some ideas! like I said, it's totally up to you and the team to define the best process ;) (I'd probably wait for feedback from others before merging too)

[noahtallen]

Suggested change

	* [ ] Install version 8.3.0-rc.1. (D44703-code)
	* [ ] Install RC (D44703-code)

I wonder if it's even helpful to refer to the RC version here. 🤔 you'd have to add extra todo items if you install multiple RCs anyways. (then people can fill in the version as needed)

[noahtallen]

probably doesn't matter to @-mention anyone for any specific item

[noahtallen]

also might not be helpful to put down diff & deploy (since every step also contains each of these items)

[WunderBart]

I like the idea of a progress tracking template, but I'm not sure if we should mix Gutenberg and CoBlocks updates in a single issue. They don't always go together and there are some differences in the process (i.e Atomic update request) that might overcomplicate this template. What do you think about keeping this only for Gutenberg, and creating the CoBlocks update issue template in CoBlocks builder repo? For me, that would make more sense because that repo is directly related to the CoBlocks update process and it's where we track & fix CoBlocks issues.
cc @sirreal @noahtallen

[sirreal]

I agree, an issue template is a great fit for exactly what we want.

However 😏 As an open source project, wp-calypso is primarily about the WordPress.com administration interface. Right now, when folks create a new issue, they're immediately presented with the default issue template.

I'm reluctant to add another step (choose an issue template) and a template that is only relevant for a very small number of folks. I'd prefer to keep a small bit of friction (copy/paste the script) that we can manage ourselves instead of introducing a small bit of friction and confusion for a large number of folks.

I'm open to being convinced otherwise 🙂

but I'm not sure if we should mix Gutenberg and CoBlocks updates in a single issue

Right, I'd expect the template to be pretty general and common to the process for either plugin— A "Plugin upgrade tracking issue" template.

[fullofcaffeine]

Howdy folks!

We've decided to abandon the GitHub issue approach. @sirreal suggested using a GitHub "issue URL" (example, we don't even need to use that library, it's just a helper).

What I'm going to do next is to close this PR, work on a version of the template taking into account your feedback here (thanks for taking the time to review!) and then generate an issue link URL. We can then create a new fieldguide about Github tracking issues for plugins and link it from other relevant fieldguides.

[fullofcaffeine]

🤔 How hard would it be to create a Gutenberg "Github Issue Template" block that would have a title and body, and if clicked (while not in write-mode), would open in GitHub with that paragraph's content as the body...

Of course, this could perhaps be considered overkill, and for now, I'll just add both links to a single page on the fieldguide, but for future templates, it could be nice. This way, to create or edit an issue template, one would just add this "GitHub Issue Template" block, edit the body, name, title and then upon saving it'd use this lib to generate the link and use it as the href.

Food for thought...

[sirreal]

🤔 How hard would it be to create a Gutenberg "Github Issue Template" block that would have a title and body, and if clicked (while not in write-mode), would open in GitHub with that paragraph's content as the body...

This is a really cool idea! We could do some initial iterations here: https://github.com/Automattic/wp-calypso/tree/master/apps/o2-blocks