feat: re-add intermediate template (#1360)

Signed-off-by: aceppaluni <[email protected]>

Author: aceppaluni

.github/ISSUE_TEMPLATE/06_intermediate_issue.yml

@@ -0,0 +1,211 @@
+name: Intermediate Issue Template
+description: Create a well-documented issue for contributors with some familiarity with the codebase
+title: "[Intermediate]: "
+labels: ["intermediate"]
+assignees: []
+
+body:
+  - type: markdown
+    attributes:
+      value: |
+        ---
+        ## **Thanks for contributing!** 😊
+
+        We truly appreciate your time and effort. 
+        This template is designed to help you create an Intermediate issue.
+
+        The goal is to create an issue for users that have:
+        - basic familiarity with the Hiero Python SDK codebase
+        - experience following our contribution workflow
+        - confidence navigating existing source code and examples
+        ---
+
+  - type: textarea
+    id: intro
+    attributes:
+      label: 🧩 Intermediate Contributors
+      description: Who is this issue for?
+      value: |
+        This issue is intended for contributors who already have some familiarity with the
+        [Hiero Python SDK](https://hiero.org) codebase and contribution workflow.
+  
+        You should feel comfortable:
+        - navigating existing source code and examples
+        - understanding SDK concepts without step-by-step guidance
+        - following the standard PR workflow without additional onboarding
+  
+        If this is your very first contribution to the project, we recommend starting with a few
+        **Good First Issues** before working on this one.
+    validations:
+      required: false
+
+  - type: markdown
+    attributes:
+      value: |
+        > [!IMPORTANT]
+        > ### 🧭 What we consider an *Intermediate Issue*
+        >
+        > This issue generally:
+        >
+        > - Requires **some knowledge of the existing codebase**, but not deep architectural knowledge
+        > - Is **narrowly scoped** and well-contained
+        > - Is **low to medium risk**, not touching highly sensitive or critical DLT logic
+        > - May involve **refactors or small feature additions**
+        > - Provides **enough documentation or examples** to reason about a solution
+        > - Often has **similar patterns elsewhere in the codebase**
+        >
+        > **What this issue is NOT:**
+        > - A beginner-friendly onboarding task
+        > - A large architectural redesign
+        > - A change requiring extensive cross-module refactors
+        > - A breaking API change
+
+  - type: textarea
+    id: problem
+    attributes:
+      label: 🐞 Problem Description
+      description: |
+        Describe the problem clearly and precisely.
+
+        You may assume the reader:
+        - understands the SDK structure
+        - can navigate `src/`, `examples/`, and `tests/`
+        - is comfortable reading existing implementations
+
+        Still, explain:
+        - what is wrong or missing
+        - where it lives in the codebase
+        - why it matters
+      value: |
+        Describe the problem here.
+    validations:
+      required: true
+
+  - type: markdown
+    attributes:
+      value: |
+        <!-- Example for Problem (hidden in submission) -->
+        ## 🐞 Problem – Example
+
+        The `TransactionGetReceiptQuery` currently exposes the `get_children()` method,
+        but the behavior is inconsistent with how child receipts are returned by the Mirror Node.
+
+        In particular:
+        - The SDK always returns only the parent receipt
+        - There is no way to opt-in to retrieving child receipts
+        - Similar query objects already support optional flags to extend the response
+
+        This limitation makes it difficult to inspect scheduled or child transactions
+        without issuing additional manual queries.
+
+        Relevant files:
+        - `src/hiero_sdk_python/query/transaction_get_receipt_query.py`
+        - `examples/query/transaction_get_receipt_query.py`
+
+  - type: textarea
+    id: solution
+    attributes:
+      label: 💡 Expected Solution
+      description: |
+        Describe the intended outcome.
+
+        This does NOT need to be a full implementation plan,
+        but should explain:
+        - what should change
+        - what should NOT change
+        - any constraints or boundaries
+      value: |
+        Describe the expected solution here.
+    validations:
+      required: true
+
+  - type: markdown
+    attributes:
+      value: |
+        <!-- Example for Solution (hidden in submission) -->
+        ## 💡 Expected Solution – Example
+
+        Introduce an optional configuration flag on `TransactionGetReceiptQuery`
+        that allows callers to explicitly request child receipts.
+
+        The change should:
+        - Be opt-in (default behavior must remain unchanged)
+        - Reuse existing response parsing logic where possible
+        - Avoid introducing breaking API changes
+
+        Example usage:
+
+        ```python
+        receipt = (
+            TransactionGetReceiptQuery()
+            .set_transaction_id(tx_id)
+            .set_include_children(True)
+            .execute(client)
+        )
+        ```
+
+  - type: textarea
+    id: implementation
+    attributes:
+      label: 🧠 Implementation Notes
+      description: |
+        Provide technical guidance to help implementation.
+
+        Examples:
+        - files or modules likely involved
+        - patterns already used elsewhere
+        - things to be careful about
+        - known edge cases
+      value: |
+        Add implementation notes here.
+    validations:
+      required: false
+
+  - type: markdown
+    attributes:
+      value: |
+        <!-- Example for Implementation Notes (hidden in submission) -->
+        ## 🧠 Implementation Notes – Example
+
+        Likely steps:
+
+        - Add an optional boolean field (e.g. `_include_children`) to
+          `TransactionGetReceiptQuery`
+        - Ensure the flag is passed to the mirror node request
+        - Update response parsing to include child receipts when present
+        - Extend the existing example in
+          `examples/query/transaction_get_receipt_query.py`
+          to demonstrate the new behavior
+
+        Similar patterns can be found in other query classes that support
+        optional response extensions.
+
+  - type: textarea
+    id: acceptance-criteria
+    attributes:
+      label: ✅ Acceptance Criteria
+      description: Define what "done" means for this issue
+      value: |
+        To merge this issue, the pull request must:
+
+        - [ ] Fully address the problem described above
+        - [ ] Follow existing project conventions and patterns
+        - [ ] Include tests or example updates where appropriate
+        - [ ] Pass all CI checks
+        - [ ] Include a valid changelog entry
+        - [ ] Use DCO and GPG-signed commits
+    validations:
+      required: true
+
+  - type: textarea
+    id: additional-info
+    attributes:
+      label: 📚 Additional Context or Resources
+      description: |
+        Add any links, references, or extra notes that may help.
+      value: |
+        - [SDK Developer Docs](https://github.com/hiero-ledger/hiero-sdk-python/tree/main/docs/sdk_developers)
+        - [SDK Developer Training](https://github.com/hiero-ledger/hiero-sdk-python/tree/main/docs/sdk_developers/training)
+
+    validations:
+      required: false