| 1 | name: "Netdata Agent: Engineering task" |
| 2 | description: "Track refactors, technical debt, and engineering follow-ups for the Netdata Agent" |
| 3 | title: "[Task]: " |
| 4 | labels: ["needs triage"] |
| 5 | type: "task" |
| 6 | body: |
| 7 | - type: markdown |
| 8 | attributes: |
| 9 | value: "### Thank you for contributing to our project!" |
| 10 | - type: markdown |
| 11 | attributes: |
| 12 | value: | |
| 13 | Use this template for internal engineering work, refactors, technical debt, |
| 14 | and follow-ups discovered during development. Please include concrete |
| 15 | evidence such as file paths, line references, pull requests, issue links, |
| 16 | review comments, or failing checks. |
| 17 | |
| 18 | For user-facing features, use the Feature request template. For defects, |
| 19 | use the Bug report template. |
| 20 | - type: textarea |
| 21 | id: problem |
| 22 | attributes: |
| 23 | label: Problem / root cause |
| 24 | description: | |
| 25 | What is wrong or risky about the current state, and why? Include concrete evidence where possible. |
| 26 | validations: |
| 27 | required: true |
| 28 | - type: textarea |
| 29 | id: clean-end-state |
| 30 | attributes: |
| 31 | label: Clean end state |
| 32 | description: | |
| 33 | What should the codebase, workflow, or project structure look like once this task is complete? |
| 34 | validations: |
| 35 | required: true |
| 36 | - type: textarea |
| 37 | id: acceptance-criteria |
| 38 | attributes: |
| 39 | label: Acceptance criteria |
| 40 | description: | |
| 41 | List observable, checkable conditions for this task to be considered done. |
| 42 | value: | |
| 43 | - |
| 44 | - |
| 45 | - |
| 46 | validations: |
| 47 | required: true |
| 48 | - type: dropdown |
| 49 | id: category |
| 50 | attributes: |
| 51 | label: Category |
| 52 | description: | |
| 53 | Select the closest category if one applies. |
| 54 | options: |
| 55 | - "refactor" |
| 56 | - "technical debt" |
| 57 | - "test debt" |
| 58 | - "docs debt" |
| 59 | - "build / CI" |
| 60 | - "follow-up from prior work" |
| 61 | validations: |
| 62 | required: false |
| 63 | - type: textarea |
| 64 | id: scope |
| 65 | attributes: |
| 66 | label: Scope boundaries |
| 67 | description: | |
| 68 | What is in scope, and what is explicitly out of scope? |
| 69 | validations: |
| 70 | required: false |
| 71 | - type: textarea |
| 72 | id: validation |
| 73 | attributes: |
| 74 | label: Validation |
| 75 | description: | |
| 76 | Which tests, scans, documentation checks, or other verification should prove the task is complete? |
| 77 | validations: |
| 78 | required: false |
| 79 | - type: textarea |
| 80 | id: risks |
| 81 | attributes: |
| 82 | label: Risks / compatibility |
| 83 | description: | |
| 84 | Note any behavior, API/schema, documentation, packaging, migration, or user-impact risks. |
| 85 | validations: |
| 86 | required: false |
| 87 | - type: textarea |
| 88 | id: related-context |
| 89 | attributes: |
| 90 | label: Related context |
| 91 | description: | |
| 92 | Link related issues, pull requests, SOWs, review comments, CI findings, or discussions. |
| 93 | validations: |
| 94 | required: false |