Lawnchair Triage Team: Official Workflow

This document is the single source of truth for our triage workflow. The goal is to create a clear, efficient, and manageable issue tracker.

The Triage Lifecycle

Every issue follows a simple lifecycle, managed by a set of status: labels. The primary goal of triage is to move an issue from needs triage to a final, actionable state.

Status Labels

status: needs triage: The default state for all new issues. This indicates that an issue has not yet been reviewed by the team.
status: needs info: The issue has been reviewed, but is missing critical information from the author (e.g., reproduction steps, device information, logcats).
status: reviewed: The issue has been validated by the team. It is a unique, well-documented, and reproducible bug or a clear feature request. This is the signal that an issue is "developer-ready."

High-Priority Labels

In addition to a status, some issues may be marked with a high-priority label.

tracking-issue: This is for high-impact issues that represent a major bug or a very common feature request. These issues serve as the official, curated list of project priorities. This label should be added in addition to status: reviewed.

For example tracking issues, visit this link to issues with tracking issue label.

Topic-Specific Labels

For clarity, we use a small set of labels to categorize issues related to specific, complex subsystems.

quickswitch issue: For issues related to the root-based QuickSwitch integration for the Recents screen.
gesture issue: For non-root gesture navigation issues, often related to OEM-specific implementations.

The Triage Process

Step 1: Find an Issue

Your primary source of work is the list of issues that need triage. Use this link to find the next available issue:

GitHub issues link

Step 2: The Investigation

Your goal is to determine the correct final state for the issue.

Check for Duplicates. Before anything else, search the issue tracker (especially for existing tracking-issues) to see if the report is a duplicate.
- If it is a duplicate, recommend closure. Example: Recommendation: Close as duplicate of #1234.
Assess Quality. Is the issue template filled out? Is the request clear?
- If the issue is very low quality (empty, rude, incomprehensible), recommend immediate closure.
- If it is missing specific, actionable information, recommend changing the status. Example: Recommendation: Change status to 'needs info'. Please provide a screen recording.
Validate the Report. If the issue is high-quality and not a duplicate, it is ready for validation.
- For Bug Reports: Attempt to reproduce the issue using the latest Nightly build.
- For Feature Requests: Assess if the request is clear and aligns with the project's vision.

Step 3: Make a Recommendation

Based on your investigation, post a comment with your final recommendation.

Recommendation: Change status to 'reviewed'. This is a valid, reproducible bug.
Recommendation: Change status to 'reviewed' and add 'tracking-issue'. This is a major crash affecting multiple users.
Recommendation: Change status to 'reviewed' and add 'gesture issue'.

Workflow for the Core Triage Team

The Core Triage Team has the ability to apply labels and close issues directly, based on their own investigations or the recommendations of other contributors.

Thank you for your work in helping to maintain a clean and effective issue tracker.