Skip to content

User Feedback Loop

Jump to bottom
MUHAMMAD DHIYAUL ATHA edited this page Mar 31, 2026 · 2 revisions

User Feedback Loop

This page defines how ATHA collects, evaluates, and ships user feedback.

Purpose

ATHA is maintained as a safety and workflow layer for pacman. The feedback loop ensures updates are driven by real user workflows and technical evidence.

Loop Stages

  1. Capture
  • Collect feedback from GitHub issues, AUR comments, and direct user reports.
  1. Reproduce
  • Reproduce the issue using the same commands and environment details.
  • Confirm expected behavior versus actual behavior.
  1. Classify
  • Safety: risks, unintended package changes, confirmation flow problems.
  • Transparency: unclear output, missing plan details, weak status signaling.
  • Auditability: missing history entries, weak traceability, unclear logs.
  1. Prioritize
  • High: data/system risk, failed package operations, broken critical command.
  • Medium: degraded UX, confusing output, non-blocking workflow defects.
  • Low: wording, formatting, minor documentation gaps.
  1. Ship
  • Implement focused fixes in small releases.
  • Document changes in Release Notes.
  • Validate with the original reproduction steps.

Feedback Submission Template

When reporting an issue, include the following:

  • ATHA version (atha --help header)
  • Command used
  • Expected behavior
  • Actual behavior
  • Full relevant output or error
  • Environment details (Arch version, shell, terminal)

Example:

Version: ATHA v2.2.0
Command: atha install --plan vim
Expected: dependency and size preview
Actual: missing size section
Output: <paste output>
Environment: Arch Linux, bash 5.x, Alacritty

Feedback Channels

Maintainer Response Policy

  • Keep responses technical, concise, and respectful.
  • Confirm reproduction status first.
  • Provide ETA only when scope is understood.
  • Close feedback with release reference once shipped.

Clone this wiki locally