Add epic issue template

[gtsiolis]

Description

This will add an Epic template according to the Epics (internal) the new Development Process (internal) using Issue Forms[1]. Alternatively, instead of the issue form this could use plain markdown and inline all comments to make the template more compact.

See how the bug report renders. See also bug_report.yml and epic.yml.

Release Notes

NONE

[roboquat]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please ask for approval from gtsiolis after the PR has been reviewed.

Associated issue: #321619

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

Needs approval from an approver in each of these files:

• OWNERS

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

[codecov]

Codecov Report

Merging #7556 (87e7b3b) into main (ac94f4f) will decrease coverage by 1.28%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             main   #7556      +/-   ##
=========================================
- Coverage   10.81%   9.53%   -1.29%     
=========================================
  Files          20      18       -2     
  Lines        1248    1080     -168     
=========================================
- Hits          135     103      -32     
+ Misses       1110     976     -134     
+ Partials        3       1       -2     

Flag	Coverage Δ
components-gitpod-cli-app	9.53% <ø> (ø)
components-local-app-app-darwin-amd64	?
components-local-app-app-darwin-arm64	?
components-local-app-app-linux-amd64	?
components-local-app-app-linux-arm64	?
components-local-app-app-windows-386	?
components-local-app-app-windows-amd64	?
components-local-app-app-windows-arm64	?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
components/local-app/pkg/auth/pkce.go
components/local-app/pkg/auth/auth.go

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

[gtsiolis]

Opened this in case it's helpful during opening a new epic. Feel free to update per need or close if this looks unessesary. 📕

Cc @csweichel @svenefftinge because Development Process (internal)

Cc @jldec @loujaybee @metcalfc because Product Sync[1] (internal)

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lucasvaltl]

Reopening this after a discussion in our product sync. We want to use this as a baseline to iterate on an epic template that aims to help standardise epics and help epic creators think about a minimal set criteria that underline the value and intent of their epic.

[loujaybee]

Given we're not actively using persona's widely in the company, I'd suggest removing this for now.

Suggested change

	- type: textarea
	id: personas
	attributes:
	label: Persona(s)
	description: Who will be impacted by this change? Which of our personas will be impacted by this change?
	placeholder: Why? To bring persona's into our work. Persona's can help us prioritise our markets. Currently, we are not focusing on the education/training persona currently. We should avoid epics which target this persona.
	validations:
	required: false

[loujaybee]

I'd suggest we remove this, I think the original intent for PRFAQ process was misunderstood, I don't think this makes sense to do as part of our epic template.

Suggested change

	- type: textarea
	id: press-release
	attributes:
	label: Press release
	description: Create excitement about the idea
	placeholder: Useful if you want to spend the extra time to get stakeholders, the team, or customers excited.
	validations:
	required: false

[gtsiolis]

Thanks for re-opening this, @lucasvaltl!

Adding a few more points in favor of merging this as I've noticed some counter points for using plain markdown here instead of a form:

1. Using Issue Forms[1] can help structure our epics but also challenge what is an epic. From what I've seen having structure in the issue template always helps, for example see [Dashboard] Access Control Page  #3401, [Dashboard] Environment Variables Page #3400, [Dashboard] Access Tokens Page #3399, and more. 💭
2. Required fields can be bypassed during epic creation by using a placeholder text like N/A (Not applicable) or TBD (To be discussed). These can give a hint on what feels unnecessary during epic creation and iterate by removing the required field if needed. 💡
3. We can always change the form back to a plain markdown issue template and have the exact same rendering in the output but without the required fields at any point in the future if we feel like the form is adding too much friction. However, this may be quite verbose if we'd like to include also the input placeholder text as comments in there. ❗
4. Above all, try something. —Franklin D. Roosevelt

[loujaybee]

Measurement and hypothesis are quite closely linked, should we merge the two for simplicity?

Suggested change

	- type: textarea
	id: measurement
	attributes:
	label: Measurement
	description: How will we know whether we've been successful / solved the problem? How will you measure the success of the epic? Ideally this metric is one of our key product metrics.
	placeholder: Important as it's how we track the outcomes (not just output) of the work and prove a change was worth it. Or it should be removed or iterated.
	validations:
	required: true
	- type: textarea
	id: hypothesis-measurement
	attributes:
	label: Hypothesis & Measurement
	description: What behaviour change are we expecting to see in our user base? And how will that behaviour change be measured? Ideally this metric is one of our key product metrics.
	placeholder: Important as it's how we track the outcomes (not just output) of the work and prove a change was worth it. Or it should be removed or iterated.
	validations:
	required: true

[loujaybee]

Suggest removing, and merging with measurement [1]

Suggested change

	- type: textarea
	id: hypothesis
	attributes:
	label: Hypothesis
	description: If we do X, we expect Y
	placeholder: Can be useful if the work is explicitly experimental.
	validations:
	required: false

[gtsiolis]

fyi: Also, friendly reminder that the moment we change anything in this issue template, we'll be deviating from the initial structure defined in the Development Process 2.0 / Epics (internal), moving away from a single source of truth (SSOT). Not advocating against any changes but bringing this up for visibility as this can also affect how we ship skateboards. ❗

[loujaybee]

Thanks @lucasvaltl and @gtsiolis !

Left a few comments to simplify and consolidate some fields. ✅ Approving as we can always iterate in future. ♻️ That said, I'll still personally continue to write out these templates as tables using tablesgenerator.com (examples: #7570, #8513).

Worth stressing that a huge aspect to these templates is 🧠 education and alignment. Creating the template is only the first tiny part. e.g. the measurement field needs to ideally be part of a cultural shift towards empowering teams with outcomes, rather than features. For as long as we're used to handing features to teams, but expecting teams to measure against outcomes, passing outcome measurements in this way will likely never feel natural.

Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. [...] The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right. Gulp [...] The process is not the thing. (source)

🙏 Happy to ship 🛹 and iterate!

[lucasvaltl]

@loujaybee I actually quite like the changes you proposed because the reduce clutter and simplify the template, which makes it less overwhelming. To move forward on them, it might be best to create a new PR for your changes so we can discuss them and merge them as an iteration on what we have now? As @gtsiolis said, we'd have to make sure we keep Development Process 2.0 / Epics (internal) in sync.