2026-09-02 11:48:55 +04:00
1 changed files with 160 additions and 0 deletions
@@ -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