|
| 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 | +- "What" are we trying to achieve |
| 21 | +- Briefly describe what this issue aims 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 | +- "Why" do we want to do this |
| 31 | +- 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, ...) |
| 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 issue |
| 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 task/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 | + |
| 103 | +## Accessibility Assessment |
| 104 | + |
| 105 | +<!-- |
| 106 | +- Outline anything related to accessibility |
| 107 | +- Assess the impact on users with disabilities |
| 108 | +- Ensure compliance with accessibility standards |
| 109 | +--> |
| 110 | + |
| 111 | +## Quality |
| 112 | + |
| 113 | +<!-- |
| 114 | +- Outline how this issue will be tested |
| 115 | +- Compatibility: |
| 116 | + - Try to ensure compatibility with all our supported versions (e.g. Kubernetes, OpenShift, product versions) |
| 117 | + - List any potential compatibility issues you're aware of |
| 118 | +--> |
| 119 | + |
| 120 | + |
| 121 | +## Release Notes |
| 122 | + |
| 123 | +<!-- |
| 124 | +- Write a short sentence or abstract that can go into the release notes |
| 125 | +- This way it is also documented for anyone finding _just this_ issue later |
| 126 | +- This does not need to be filled out during refinement but can/should be added later before closing the issue |
| 127 | +--> |
| 128 | + |
| 129 | +<!-- |
| 130 | +# Todos / Remarks |
| 131 | +
|
| 132 | +NOTE: This section is not meant to be displayed, therefore it is in a comment. You can leave it here, commented, or delete it. |
| 133 | +
|
| 134 | +- [ ] 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. |
| 135 | +- [ ] Delete everything that is irrelevant for this particular issue. |
| 136 | +- [ ] Add appropriate labels |
| 137 | +
|
| 138 | +
|
| 139 | +- There are different types of issues/epics, which might require different subsets (or no) sections of the above |
| 140 | + - e.g. "Update product versions" |
| 141 | + - e.g. "Implement new feature" |
| 142 | +- In the whole issue write out all acronyms that are not industry standard at least once. Example: OpenPolicyAgent (OPA) |
| 143 | +- If this is part of another issue please make sure to link the two in both places (parent & child) |
| 144 | +- If CRD changes (not necessarily breaking) are required, make sure structs/enums/fields are documented and are rendered properly in the CRD generation tool |
| 145 | +- Also see our [Development Philosophy](https://app.nuclino.com/Stackable/Stackable-Handbook/Development-Philosophy-ba280b20-b8cd-4fb6-a863-ff6d8c9f1af2) |
| 146 | +--> |
0 commit comments