Skip to content

Commit d17a3aa

Browse files
lfranckelfrancke
authored
Create advanced-issue
1 parent 7fe9f2f commit d17a3aa

File tree

1 file changed

+144
-0
lines changed

1 file changed

+144
-0
lines changed

‎.github/ISSUE_TEMPLATE/advanced-issue

Lines changed: 144 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,144 @@
1+
---
2+
name: Advanced Issue
3+
about: This template is mostly used for Stackable staff. It contains an elaborate checklist of things to consider/refine when creating an issue.
4+
title: ''
5+
labels: ''
6+
assignees: ''
7+
8+
---
9+
10+
# Title
11+
12+
<!--
13+
- Ensure the title is specific and descriptive
14+
- Avoid acronyms if possible
15+
-->
16+
17+
## Description
18+
19+
<!--
20+
- Briefly describe what this epic aims to achieve
21+
- "What" are we trying to achieve
22+
23+
Examples:
24+
- As devs we want an OpenShift certification process that is automated as far as possible.
25+
-->
26+
27+
## Value
28+
29+
<!--
30+
- Clearly define the value this brings to customers or why else it is important if not _directly_ for customers (e.g. internal tooling or improvements, technical debt, ...)
31+
- "Why" do we want to do this
32+
- Explain how to showcase the outcome of this issue to users/customers or developers (add tasks for this if needed), how can we market this
33+
34+
Examples:
35+
- "We want CRD versioning so we can make backwards compatible changes to our CRDs"
36+
- "We want CRD versioning because we're making contractual stability promises to our customers around CRDs, and we can only honor these using CRD versioning"
37+
- "Manual steps in the OpenShift certification process have lead to costly (time wise) errors in the past, these steps also mean that it is currently not easy for us to do a 'quick' patch release: These changes would allow this leading to a better experience for OpenShift users as well as making it easier to fulfill our contractual obligations, which might require us to release patches on short notice."
38+
-->
39+
40+
## Dependencies
41+
42+
<!--
43+
- Consider and name any internal and external dependencies and constraints
44+
- List all known necessary resources (e.g. cluster, customers, people, repositories, libraries...)
45+
46+
Examples:
47+
- This epic will require changes to docker image XY, it will require a change to the listener operator, and we'll need an OpenShift 4.15 cluster to test
48+
-->
49+
50+
## Tasks
51+
52+
<!--
53+
- List all known tasks that need to be completed to finish this epic
54+
- Not all tasks might be known at the beginning!
55+
- Task types
56+
- Technical
57+
- Testing
58+
- Documentation
59+
- Marketing / Showcase
60+
- Initial tasks might just be _separate_ research tasks, which, upon completion, lead to more tasks in this epic
61+
- When creating the list of tasks make sure to put them in an order and focus on creating minimum marketable features
62+
- This is the _Definition of Done_ which (mostly, exception are marketing tasks) represents the technical "completeness" of a task
63+
64+
Example:
65+
- Marketing: Prepare a blog post outlining the new CRD versioning support, our policies around CRD versioning and the current versions we do support
66+
-->
67+
68+
## Acceptance Criteria
69+
70+
<!--
71+
- List acceptance criteria
72+
- Define clear objective criteria for when we would consider this issue "Done"
73+
- It differs from the _Definition of Done_ in _Tasks_ above by focusing on the "what" (an expanded version of the Description)
74+
- One example that should always if relevant be included is accessibility:
75+
- We don't yet do much UI work so this is underspecified right now
76+
77+
Example:
78+
- Bad example: All tests pass (that should be implied for anything and is not a functional requirement)
79+
- Good examples:
80+
- Traces are exported via OTLP and can be seen in Jaeger (or equivalent trace visualisation tool) (achieves a goal, while only being as prescriptive as necessary)
81+
- CRD versioning is seamlessly integrated into our operators, allowing for the specification of multiple versions within CRDs.
82+
- Backward compatibility is maintained for at least two previous versions of CRDs.
83+
-
84+
85+
-->
86+
87+
## (Information Security) Risk Assessment
88+
89+
<!--
90+
- Outline any information security (this includes cybersecurity) or any other obvious risks and the controls how to mitigate them
91+
- This is relevant for ISO 27001, the Cyber Resilience Act and other standards/norms
92+
- Examples:
93+
- Does this open any new ports? If so, how are they secured
94+
- Do we ask for the least amount of privileges required
95+
- Does this require any secrets?
96+
- Which ciphers might be used and how can they be configured
97+
- Does it introduce a dependency? Have you reviewed it for vulnerabilities, licenses issues, recent activity etc.
98+
- Bugs in this feature could lead to data loss for our customers
99+
- ...
100+
-->
101+
102+
## Accessibility Assessment
103+
104+
<!--
105+
- Outline anything on
106+
107+
-->
108+
109+
## Quality
110+
111+
<!--
112+
- Outline how this epic will be tested
113+
- Compatibility:
114+
- Try to ensure compatibility with all our supported versions (e.g. Kubernetes, OpenShift, product versions)
115+
- List any potential compatibility issues you're aware of
116+
-->
117+
118+
119+
## Release Notes
120+
121+
<!--
122+
- Write a short sentence or abstract that can go into the release notes
123+
- This way it is also documented for anyone finding _just this_ epic later
124+
- This does not need to be filled out during refinement but can/should be added later before closing the epic
125+
-->
126+
127+
<!--
128+
# Todos / Remarks
129+
130+
NOTE: This section is not meant to be displayed, therefore it is in a comment. You can leave it here, commented, or delete it.
131+
132+
- [ ] Fill out as many sections above as you can, not everything is known at the beginning. Please leave a comment in any section that is unknown.
133+
- [ ] Delete everything that is irrelevant for this particular issue.
134+
- [ ] Add appropriate labels
135+
136+
137+
- There are different types of epics, which might require different subsets (or no) sections of the above
138+
- e.g. "Update product versions"
139+
- e.g. "Implement new feature"
140+
- In the whole issue write out all acronyms that are not industry standard at least once. Example: OpenPolicyAgent (OPA)
141+
- If this is part of another issue please make sure to link the two in both places (parent & child)
142+
- If CRD changes (not necessarily breaking) are required, make sure structs/enums/fields are documented and are rendered properly in the CRD generation tool
143+
- Also see our [Development Philosophy](https://app.nuclino.com/Stackable/Stackable-Handbook/Development-Philosophy-ba280b20-b8cd-4fb6-a863-ff6d8c9f1af2)
144+
-->

0 commit comments

Comments
 (0)