Standardise issue labels and add structured issue templates

[Talie5in]

Summary

This PR standardises the MeshCore issue labels and introduces structured issue templates for bug reports and feature requests.

The goal is to make issue triage easier, reduce duplicate reports, and provide consistent filtering by area, firmware variant, and platform.

An example of some issues can be viewed on my fork -> https://github.com/Talie5in/MeshCore/issues

What changed

Added structured issue templates

This PR adds:

• Bug Report template
• Feature Request template
• Issue template config to disable blank issues

The templates ask contributors to search existing issues first and confirm that the report relates to MeshCore, not MeshOS.

Added component selection

Bug reports and feature requests now include structured selections for:

• Firmware - Community
• Firmware - Ripple
• Client - MeshCore App
• UI - TDeck / Ripple GUI
• CLI / Tooling
• Documentation
• Unsure

Feature requests also include:

• Add Support for New Hardware
• Protocol / Routing

Added platform selection

Platform selection is intentionally limited to MCU family:

• ESP32
• nRF52
• Not platform specific
• Unsure

This avoids board-level label noise while still keeping useful triage information.

Label model

Labels are grouped by purpose:

Area labels

• area:firmware
• area:client
• area:ui
• area:tooling
• area:hardware
• area:protocol
• area:routing
• area:documentation

Firmware variant labels

• firmware:community
• firmware:ripple

Platform labels

• platform:esp32
• platform:nrf52

Triage labels

• needs-triage
• needs-review
• needs-info

Type labels

• bug
• enhancement

Colour grouping

Label colours are grouped intentionally to make the issue list easier to scan:

• Blue spectrum: core areas such as firmware, client, hardware, documentation
• Green: UI
• Teal: tooling / CLI / build scripts
• Purple: protocol and routing
• Green shades: firmware variants
• Purple shades: platform labels
• Warm colours: bug, enhancement, and triage states

This creates visual grouping without needing to read every label individually.

You can view the labels and colours here on my fork -> https://github.com/Talie5in/MeshCore/labels

Existing label cleanup

The included label sync script renames existing labels where possible:

• Firmware → area:firmware
• MeshCore App → area:client
• TDeck / Ripple GUI → area:ui
• New Hardware Support → area:hardware
• documentation → area:documentation

The MeshOS label is removed, as MeshOS is now a separate project.

Included label sync script

The script is idempotent and can be safely re-run. It creates missing labels, renames existing labels, and updates colours/descriptions.

#!/usr/bin/env bash
set -euo pipefail

rename_if_exists() {
  OLD="$1"
  NEW="$2"

  if gh label list --limit 300 | grep -q "^${OLD}[[:space:]]"; then
    echo "Renaming: $OLD -> $NEW"
    gh label edit "$OLD" --name "$NEW" || true
  fi
}

create_or_update() {
  NAME="$1"
  COLOR="$2"
  DESC="$3"

  if gh label list --limit 300 | grep -q "^${NAME}[[:space:]]"; then
    echo "Updating: $NAME"
    gh label edit "$NAME" --color "$COLOR" --description "$DESC"
  else
    echo "Creating: $NAME"
    gh label create "$NAME" --color "$COLOR" --description "$DESC"
  fi
}

rename_if_exists "Firmware" "area:firmware"
rename_if_exists "MeshCore App" "area:client"
rename_if_exists "TDeck / Ripple GUI" "area:ui"
rename_if_exists "New Hardware Support" "area:hardware"
rename_if_exists "documentation" "area:documentation"

create_or_update "bug" "d73a4a" "Something is not working"
create_or_update "enhancement" "fbca04" "New feature or request"
create_or_update "needs-triage" "f9d0c4" "Needs initial review"
create_or_update "needs-review" "fef2c0" "Needs deeper technical review"
create_or_update "needs-info" "ffcc00" "Missing required information"

create_or_update "area:firmware" "1d76db" "Firmware-related issue"
create_or_update "area:client" "2188ff" "MeshCore client/app issue"
create_or_update "area:hardware" "0052cc" "Hardware or board support"
create_or_update "area:documentation" "6a737d" "Documentation"

create_or_update "area:ui" "2ecc71" "UI / display layer issue"
create_or_update "area:tooling" "1abc9c" "CLI / tooling / build systems"

create_or_update "area:protocol" "6f42c1" "Protocol-level behaviour"
create_or_update "area:routing" "8e44ad" "Routing / mesh path logic"

create_or_update "firmware:community" "27ae60" "Community firmware"
create_or_update "firmware:ripple" "145a32" "Ripple firmware"

create_or_update "platform:esp32" "8e44ad" "ESP32-based devices"
create_or_update "platform:nrf52" "9b59b6" "nRF52-based devices"

if gh label list --limit 300 | grep -q "^MeshOS[[:space:]]"; then
  echo "Deleting: MeshOS"
  gh label delete "MeshOS" --yes
fi

echo "Labels synced."

Automation

This PR also includes .github/workflows/auto-label-issues.yml.

The workflow runs when an issue is opened or edited and automatically applies labels based on the structured issue form selections.

For example:

• Firmware - Community → area:firmware, firmware:community
• Firmware - Ripple → area:firmware, firmware:ripple
• Client - MeshCore App → area:client
• UI - TDeck / Ripple GUI → area:ui
• CLI / Tooling → area:tooling
• New Hardware Support → area:hardware
• Protocol / Routing → area:protocol, area:routing
• Documentation → area:documentation
• ESP32 → platform:esp32
• nRF52 → platform:nrf52
• Unsure → needs-review

All new or edited issues also receive needs-triage.

This keeps labels consistent without relying on manual triage for the first pass.