.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

.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