From 9682a89dea99b868763f4cd3e7567f34a911e6fa Mon Sep 17 00:00:00 2001
From: "Kwiatosz, Krzysztof" <krzysztof.kwiatosz@sap.com>
Date: Fri, 28 Jun 2024 11:58:39 +0200
Subject: [PATCH] Modify GH issue template for New Features

---
 .github/ISSUE_TEMPLATE/feature-request.md | 59 +++++++++++++++++++++--
 1 file changed, 56 insertions(+), 3 deletions(-)

diff --git a/.github/ISSUE_TEMPLATE/feature-request.md b/.github/ISSUE_TEMPLATE/feature-request.md
index 8040e5584..35ff1cf47 100644
--- a/.github/ISSUE_TEMPLATE/feature-request.md
+++ b/.github/ISSUE_TEMPLATE/feature-request.md
@@ -6,16 +6,69 @@ about: Suggest an improvement to the project
 <!-- Thank you for your contribution. Before you submit the issue:
 1. Search open and closed issues for duplicates.
 2. Read the contributing guidelines.
+3. Fill in each section with as much detail as possible to ensure a clear understanding of the request.
 -->
 
 **Description**
 
-<!-- Provide a clear and concise description of the feature. -->
-
+<!--
+Provide a detailed description of the feature you are proposing.
+Explain WHAT the feature is, HOW it should work, and any relevant details.
+Try to answer the following questions:
+- What problem does this feature solve?
+- How should the feature behave?
+- Are there any specific functionalities it must include?
+- Are there any known constraints?
+-->
 **Reasons**
 
-<!-- Explain why we should add this feature. Provide use cases to illustrate its benefits. -->
+<!--
+Explain why this feature is necessary or beneficial.
+Discuss the motivation behind the request and how it aligns with the project's goals.
+Consider including answers to the following:
+- Why is this feature important?
+- What use cases does it support?
+- How does it improve the user experience or functionality of the project?
+-->
+
+**Acceptance Criteria**
+
+<!--
+Define the specific requirements that must be met for this feature to be considered complete.
+Use clear, measurable, and testable criteria.
+Acceptance criteria might include:
+- Specific behaviors or outcomes.
+- Setting a performance benchmarks.
+- Compatibility requirements.
+Example:
+- Users should be able to configure a numeric setting via Custom Resource.
+- The new setting must be validated before its applied.
+- The new setting, when applied, is visible in the status of Custom Resource.
+-->
+ - [ ] expected behaviors, outcomes ... ?
+ - [ ] ... new docs / update docs ... ?
+
+**Testing Strategy (DoD)**
+<!--
+Outline the strategy for testing this feature to ensure it meets the acceptance criteria.
+Consider what constitutes the "Definition of Done" (DoD).
+Include details on:
+- automated unit tests and integration tests.
+- any planned manual testing procedures.
+- target environment type: k3d, gardener, managed kyma runtime
+-->
+ - automated unit test for the new logic
+ - automated integration test (new test suite? extending existing test?)
+ - automated/manual test on SKR ?
 
 **Attachments**
 
 <!-- Attach any files, links, code samples, or screenshots that will convince us to your idea. -->
+
+**Related Issues**
+
+<!-- Include links or references to:
+- Bugs that this feature might address.
+- Other github issues that are dependent on or related to this one.
+- Relevant discussions, decisions or threads.
+-->
\ No newline at end of file