diff --git a/.gitea/ISSUE_TEMPLATE/feature_request.yaml b/.gitea/ISSUE_TEMPLATE/feature_request.yaml new file mode 100644 index 0000000..9aa7d10 --- /dev/null +++ b/.gitea/ISSUE_TEMPLATE/feature_request.yaml @@ -0,0 +1,129 @@ +name: "Feature Request" +description: "Suggest a new feature or enhancement for this project" +title: "[FEATURE]: " +labels: ["enhancement"] +body: + - type: markdown + attributes: + value: | + ## โš ๏ธ Before You Begin + Please ensure you have: + - [ ] Searched existing issues (open and closed) to avoid duplicates + - [ ] Reviewed the [project documentation](https://git.vmn.su/max/audio_splitter/wiki) for existing functionality + - [ ] Confirmed this is a feature request, not a bug or configuration question + + + - type: textarea + id: problem + attributes: + label: "๐ŸŽฏ Problem Statement" + description: "What problem does this feature solve? What can't you do today?" + placeholder: | + I'm always frustrated when... + Currently, it's hard/impossible to... + This feature would help me because... + validations: + required: true + + - type: textarea + id: solution + attributes: + label: "๐Ÿ’ก Proposed Solution" + description: "Describe the solution you'd like to see" + placeholder: | + A clear description of what you want to happen. + If you have a specific API, UI, or implementation in mind, describe it here. + validations: + required: true + + - type: textarea + id: alternatives + attributes: + label: "๐Ÿ”„ Alternatives Considered" + description: "What alternative solutions or workarounds have you considered?" + placeholder: | + - Alternative A: ... + - Workaround B: ... + - Why these don't fully solve the problem + validations: + required: false + + - type: textarea + id: usecase + attributes: + label: "๐Ÿ‘ค Use Case / Persona" + description: "Who benefits from this feature and in what context?" + placeholder: | + As a [type of user], I want to [do something] so that [I achieve some benefit]. + Example: "As a project maintainer, I want to bulk-close issues by label so that I can clean up stale tickets faster." + validations: + required: false + + - type: textarea + id: screenshots + attributes: + label: "๐Ÿ“ธ Screenshots" + description: "If you can, provide screenshots or diagrams of the proposed feature" + placeholder: "Drag and drop images or paste links..." + validations: + required: false + + - type: markdown + attributes: + value: | + --- + ## ๐Ÿ”ง Implementation Details (Optional) + The following sections are for contributors who want to implement this feature. + + - type: textarea + id: technical + attributes: + label: "โš™๏ธ Technical Approach" + description: "If you have ideas about how to implement this, share them here" + placeholder: | + - Which components/modules would be affected? + - Any database schema changes? + - API design considerations? + validations: + required: false + + - type: textarea + id: acceptance + attributes: + label: "โœ… Acceptance Criteria" + description: "What does 'done' look like for this feature?" + placeholder: | + - [ ] Feature works in the UI + - [ ] API endpoints are documented + - [ ] Tests are added + - [ ] Documentation is updated + validations: + required: false + + - type: dropdown + id: contribution + attributes: + label: "๐Ÿค Are you willing to contribute this feature?" + description: "Knowing if you can help implement this helps us prioritize" + options: + - "Yes, I can contribute" + - "Yes, but I need guidance" + - "No, but I can test/review" + - "No, I'm just requesting" + validations: + required: true + + - type: checkboxes + id: checklist + attributes: + label: "โœ… Submission Checklist" + description: "Please confirm the following before submitting" + options: + - label: "I have searched for existing issues (open and closed) that request the same feature" + required: true + - label: "I have explained the problem this feature solves" + required: true + - label: "I have described a concrete solution or direction" + required: true + - label: "I have considered alternatives and explained why they fall short" + required: false diff --git a/.gitea/ISSUE_TEMPLATE/refactor.yaml b/.gitea/ISSUE_TEMPLATE/refactor.yaml new file mode 100644 index 0000000..0a40aad --- /dev/null +++ b/.gitea/ISSUE_TEMPLATE/refactor.yaml @@ -0,0 +1,160 @@ +name: "Refactor Request" +description: "Propose a code restructuring or cleanup with no behavior change" +title: "[REFACTOR]: " +labels: ["refactoring"] +body: + - type: markdown + attributes: + value: | + ## โš ๏ธ Before You Begin + Please ensure you have: + - [ ] Searched existing issues (open and closed) to avoid duplicates + - [ ] Reviewed the [project documentation](https://git.vmn.su/max/audio_splitter/wiki) for architecture guidelines + - [ ] Confirmed this is a refactor (code restructuring with NO behavior change), not a bug fix or new feature + + + - type: textarea + id: problem + attributes: + label: "๐ŸŽฏ Problem Statement" + description: "What pain points does the current code cause? Why is this refactor needed?" + placeholder: | + The current implementation is difficult to maintain because... + This code has accumulated technical debt due to... + I'm constantly frustrated when working with this module because... + validations: + required: true + + - type: textarea + id: scope + attributes: + label: "๐Ÿ“‚ Scope" + description: "Which files, modules, or components need refactoring? Be specific." + placeholder: | + - File paths: `src/auth/`, `internal/handler/` + - Component: `UserService` class + validations: + required: true + + - type: textarea + id: current-state + attributes: + label: "๐Ÿ” Current State" + description: "Describe the current code structure, its issues, and why it's problematic" + placeholder: | + - The function `processUser()` is 500+ lines long + - Duplicated logic across 3 different files + - Mixed concerns (business logic + HTTP handling) + - Poor test coverage makes changes risky + - Naming is unclear and inconsistent + validations: + required: true + + - type: textarea + id: proposed-changes + attributes: + label: "๐Ÿ’ก Proposed Solution" + description: "What should the code look like after the refactor?" + placeholder: | + - Extract `processUser()` into smaller, focused functions + - Consolidate duplicated logic into a shared utility + - Separate business logic from HTTP handlers + - Introduce interfaces for better testability + - Rename variables and functions for clarity + validations: + required: true + + - type: textarea + id: constraints + attributes: + label: "๐Ÿšซ Constraints" + description: "What must NOT change? Public APIs, behavior, backward compatibility, performance characteristics?" + placeholder: | + - All public APIs must remain identical + - Database schema must not change + - External behavior must be identical + - Response formats must stay the same + - Performance must not degrade + validations: + required: true + + - type: textarea + id: benefits + attributes: + label: "๐Ÿ“ˆ Expected Benefits" + description: "What improvements will this refactor bring?" + placeholder: | + - Improved maintainability + - Better testability + - Reduced code duplication + - Clearer separation of concerns + - Easier onboarding for new contributors + validations: + required: false + + - type: textarea + id: risks + attributes: + label: "โš ๏ธ Risks & Mitigations" + description: "What could go wrong, and how will you mitigate it?" + placeholder: | + - Risk: Regression bugs + Mitigation: Comprehensive test coverage before and after + - Risk: Large diff making code review difficult + Mitigation: Break into smaller, incremental PRs + validations: + required: false + + - type: textarea + id: testing + attributes: + label: "๐Ÿงช Testing Strategy" + description: "How will you ensure the refactor doesn't break existing functionality?" + placeholder: | + - Existing test suite must pass + - Add regression tests before refactoring + - Run benchmarks to ensure no performance regression + - Manual testing of critical paths + validations: + required: true + + - type: textarea + id: alternatives + attributes: + label: "๐Ÿ”„ Alternatives Considered" + description: "What other approaches did you consider, and why did you reject them?" + placeholder: | + - Alternative A: Complete rewrite โ€” rejected because too risky + - Alternative B: Gradual deprecation โ€” rejected because too slow + validations: + required: false + + - type: dropdown + id: contribution + attributes: + label: "๐Ÿค Are you willing to contribute this refactor?" + description: "Knowing if you can help implement this helps us prioritize" + options: + - "Yes, I can contribute" + - "Yes, but I need guidance" + - "No, but I can review" + - "No, I'm just suggesting" + validations: + required: true + + - type: checkboxes + id: checklist + attributes: + label: "โœ… Submission Checklist" + description: "Please confirm the following before submitting" + options: + - label: "I have searched for existing issues (open and closed) that request the same refactor" + required: true + - label: "I have clearly explained the problem this refactor solves" + required: true + - label: "I have described the scope of the refactor (specific files/modules)" + required: true + - label: "I have identified what must NOT change (APIs, behavior, backward compatibility)" + required: true + - label: "I have described how the refactor will be tested" + required: true