audio_splitter/.gitea/ISSUE_TEMPLATE/refactor.yaml

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