Skip to content

Commit d53489c

Browse files
MonaaEidMonaaEid
authored
feat: Create advanced issue template for contributors (#1152)
Signed-off-by: MonaaEid <[email protected]>
1 parent 8f7539e commit d53489c

File tree

2 files changed

+227
-0
lines changed

2 files changed

+227
-0
lines changed

‎.github/ISSUE_TEMPLATE/06_advanced_issue.yml‎

Lines changed: 226 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,226 @@
1+
name: Advanced Issue Template
2+
description: Create a high-impact issue for experienced contributors with deep familiarity with the codebase
3+
title: "[Advanced]: "
4+
labels: ["advanced"]
5+
assignees: []
6+
7+
body:
8+
- type: markdown
9+
attributes:
10+
value: |
11+
---
12+
## **Thanks for contributing!** 🚀
13+
14+
We truly appreciate your interest in tackling an **Advanced issue**.
15+
16+
This template is designed for work that requires **deep familiarity with the Hiero Python SDK**
17+
and confidence making changes that may span multiple modules or affect core behavior.
18+
19+
The goal is to create issues for contributors who:
20+
- have strong familiarity with the Hiero Python SDK internals
21+
- are comfortable reasoning about trade-offs and design decisions
22+
- can work independently with minimal guidance
23+
---
24+
25+
- type: textarea
26+
id: intro
27+
attributes:
28+
label: 🧠 Advanced Contributors
29+
description: Who is this issue intended for?
30+
value: |
31+
This issue is intended for contributors who are already very familiar with the
32+
[Hiero Python SDK](https://hiero.org) codebase and its architectural patterns.
33+
34+
You should feel comfortable:
35+
- navigating multiple modules across `src/`
36+
- understanding and modifying core SDK abstractions
37+
- reasoning about API design and backwards compatibility
38+
- updating or extending tests, examples, and documentation as needed
39+
- making changes that may affect public-facing behavior
40+
41+
New developers should start with
42+
**Good First Issues** or **Intermediate Issues** first.
43+
validations:
44+
required: false
45+
46+
- type: markdown
47+
attributes:
48+
value: |
49+
> [!WARNING]
50+
> ### 🧭 What we consider an *Advanced Issue*
51+
>
52+
> This issue typically:
53+
>
54+
> - Requires **deep understanding of existing SDK design and behavior**
55+
> - May touch **core abstractions**, shared utilities, or cross-cutting concerns
56+
> - May involve **non-trivial refactors**, design changes, or behavior extensions
57+
> - Has **medium to high risk** if implemented incorrectly
58+
> - Requires careful consideration of **backwards compatibility**
59+
> - May require updating **tests, examples, and documentation together**
60+
>
61+
> **What this issue is NOT:**
62+
> - A simple bug fix
63+
> - A narrowly scoped refactor
64+
> - A task solvable by following existing patterns alone
65+
>
66+
> 📖 Helpful references:
67+
> - `docs/sdk_developers/training`
68+
> - `docs/sdk_developers/project_structure.md`
69+
> - `docs/sdk_developers/rebasing.md`
70+
71+
- type: textarea
72+
id: problem
73+
attributes:
74+
label: 🐞 Problem Description
75+
description: |
76+
Describe the problem in depth.
77+
78+
You may assume the reader:
79+
- understands the overall SDK architecture
80+
- can navigate and reason about multiple modules
81+
- is comfortable reading and modifying core logic
82+
83+
Clearly explain:
84+
- what the current behavior is
85+
- why it is insufficient or incorrect
86+
- which components or layers are involved
87+
- any relevant historical or design context
88+
value: |
89+
Describe the problem here.
90+
validations:
91+
required: true
92+
93+
- type: markdown
94+
attributes:
95+
value: |
96+
<!-- Example for Problem (hidden in submission) -->
97+
## 🐞 Problem – Example
98+
99+
The current transaction execution pipeline tightly couples
100+
receipt retrieval, record retrieval, and retry logic into a single
101+
execution flow.
102+
103+
This coupling makes it difficult to:
104+
- customize retry behavior
105+
- extend execution semantics for scheduled or mirror-node-backed workflows
106+
- test individual stages of transaction execution in isolation
107+
108+
Several downstream SDK features would benefit from a clearer separation
109+
of concerns in this area.
110+
111+
Relevant areas:
112+
- `src/hiero_sdk_python/transaction/`
113+
- `src/hiero_sdk_python/execution/`
114+
- `src/hiero_sdk_python/client/`
115+
116+
- type: textarea
117+
id: solution
118+
attributes:
119+
label: 💡 Proposed / Expected Solution
120+
description: |
121+
Describe the intended direction or design.
122+
123+
This should include:
124+
- the high-level approach
125+
- any new abstractions or changes to existing ones
126+
- constraints (e.g. backwards compatibility, performance, API stability)
127+
- known alternatives and why they were rejected (if applicable)
128+
129+
A full design document is not required, but reasoning and intent should be clear.
130+
value: |
131+
Describe the proposed solution here.
132+
validations:
133+
required: true
134+
135+
- type: markdown
136+
attributes:
137+
value: |
138+
<!-- Example for Solution (hidden in submission) -->
139+
## 💡 Proposed Solution – Example
140+
141+
Introduce a dedicated execution pipeline abstraction that separates:
142+
- transaction submission
143+
- receipt polling
144+
- record retrieval
145+
- retry and timeout logic
146+
147+
The new design should:
148+
- preserve existing public APIs
149+
- allow advanced users to override or extend execution behavior
150+
- make individual stages independently testable
151+
152+
Existing transaction execution should be reimplemented
153+
using the new pipeline internally.
154+
155+
- type: textarea
156+
id: implementation
157+
attributes:
158+
label: 🧠 Implementation & Design Notes
159+
description: |
160+
Provide detailed technical guidance.
161+
162+
This section is especially important for Advanced issues.
163+
164+
Consider including:
165+
- specific modules or classes involved
166+
- suggested refactoring strategy
167+
- migration or deprecation concerns
168+
- testing strategy
169+
- performance or security considerations
170+
value: |
171+
Add detailed implementation notes here.
172+
validations:
173+
required: false
174+
175+
- type: markdown
176+
attributes:
177+
value: |
178+
<!-- Example for Implementation Notes (hidden in submission) -->
179+
## 🧠 Implementation Notes – Example
180+
181+
Suggested approach:
182+
183+
- Introduce a new `ExecutionPipeline` abstraction under
184+
`src/hiero_sdk_python/execution/`
185+
- Refactor existing transaction execution logic to delegate
186+
to this pipeline
187+
- Ensure existing public APIs remain unchanged
188+
- Add focused unit tests for each pipeline stage
189+
- Update at least one example to demonstrate extensibility
190+
191+
Care should be taken to avoid breaking timeout semantics
192+
relied upon by existing users.
193+
194+
- type: textarea
195+
id: acceptance-criteria
196+
attributes:
197+
label: ✅ Acceptance Criteria
198+
description: Define what "done" means for this issue
199+
value: |
200+
To merge this issue, the pull request must:
201+
202+
- [ ] Fully address the problem and design goals described above
203+
- [ ] Maintain backwards compatibility unless explicitly approved otherwise
204+
- [ ] Follow existing architectural and coding conventions
205+
- [ ] Include comprehensive tests covering new and existing behavior
206+
- [ ] Update relevant examples and documentation
207+
- [ ] Pass all CI checks
208+
- [ ] Include a valid changelog entry
209+
- [ ] Use DCO and GPG-signed commits
210+
validations:
211+
required: true
212+
213+
- type: textarea
214+
id: additional-info
215+
attributes:
216+
label: 📚 Additional Context, Links, or Prior Art
217+
description: |
218+
Add any references that may help:
219+
- design docs
220+
- prior discussions
221+
- related issues or PRs
222+
- external references
223+
value: |
224+
Optional.
225+
validations:
226+
required: false

‎CHANGELOG.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -51,6 +51,7 @@ This changelog is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.
5151
- Add a workflow to notify the team when issues are labeled as “good first issues” or identified as candidates for that label: `bot-gfi-notify-team.yml`(#1115)
5252
- Added __str__ and __repr__ to AccountBalance
5353
- Added GitHub workflow that makes sure newly added test files follow pytest test files naming conventions (#1054)
54+
- Added advanced issue template for contributors `.github/ISSUE_TEMPLATE/06_advanced_issue.yml`.
5455

5556
### Changed
5657
- Pylint cleanup for token_airdrop_transaction_cancel.py (#1081) [@tiya-15](https://github.com/tiya-15)

0 commit comments

Comments
 (0)