Enable non-engineer contributions (PM, UX Designer) to the OSS project

## What would you like to be added?

A structured framework that enables non-engineers (Product Managers, UX Designers, UX Researchers) to contribute meaningfully to the Gemini CLI OSS project. This includes new Issue templates, labels, contribution guidelines, and community processes specifically designed for non-code contributions.

## Why is this needed?

### The strategic gap

Gemini CLI's ROADMAP.md states a guiding principle:

> "Free and Open Source: Foster a thriving open source community where cost isn't a barrier to personal use, and PRs get merged quickly."

And ROADMAP.md explicitly welcomes:

> "Whether you're a developer, **a designer**, or just an enthusiastic user"

However, the current contribution infrastructure is almost entirely designed for engineers:

| Current state | Evidence |
|--------------|----------|
| CONTRIBUTING.md only defines code and docs contribution paths | No PM/UX contribution path exists |
| Issue templates: Bug Report, Feature Request, Website Issue only | No UX feedback or user research template |
| `good first issue` label: 0 open issues | No entry point for newcomers |
| `help-wanted`: 128 issues, all requiring code skills | Non-engineers cannot contribute to any of them |
| Quality assurance relies on maintainer dogfooding | No structured UX review process from external contributors |
| CSAT is 83%, but no public mechanism for UX improvement feedback loop | User research insights have no home |

### Why this matters for product growth

Gemini CLI aims to expand beyond developers to broader adoption within organizations. As stated in the product documentation, enterprise deployment involves IT administrators, team leads, and non-engineering stakeholders who configure policies, evaluate tools, and make purchasing decisions.

**If only engineers shape the product, the product will only work well for engineers.** Expanding to Product Managers, UX Designers, and other non-technical contributors will:

1. **Improve usability** - UX professionals can identify friction points engineers overlook (e.g., onboarding flow, error messages, CLI output readability)
2. **Broaden adoption** - A tool shaped by diverse perspectives serves diverse users
3. **Strengthen the OSS community** - More contributor types = more sustainable community
4. **Improve competitive position** - In the coding tools market where Anthropic leads with 54% share, superior UX could be a differentiator
5. **Align with stated goals** - The ROADMAP lists "User Experience" as a key focus area

### Current competitive context

The AI CLI tools market is rapidly growing with 15+ competing tools. Gemini CLI's stated quality goal is to be "reliably ranked among the best agentic tools as measured by SWE Bench, Terminal Bench, and **CSAT**." Achieving high CSAT requires systematic UX contribution — something the current OSS structure does not support.

## Proposed changes

### 1. New Issue templates for non-engineer contributions

Add the following Issue templates alongside the existing Bug Report and Feature Request:

#### a. UX Feedback Report

```yaml
name: 'UX Feedback'
description: 'Report a usability issue or suggest a UX improvement'
labels:
- 'area/ux'
- 'type/ux-feedback'
body:
- type: textarea
id: scenario
attributes:
label: 'What were you trying to do?'
description: 'Describe the task or goal you were working on.'
validations:
required: true
- type: textarea
id: experience
attributes:
label: 'What was your experience?'
description: 'Describe what happened. Was anything confusing, slow, or frustrating?'
validations:
required: true
- type: textarea
id: expected
attributes:
label: 'What would have been better?'
description: 'Describe how you think the experience could be improved.'
- type: textarea
id: screenshots
attributes:
label: 'Screenshots or recordings'
description: 'If possible, add screenshots or terminal recordings (e.g., asciinema).'
- type: dropdown
id: experience-level
attributes:
label: 'Your experience level with CLI tools'
options:
- 'Beginner (rarely use terminal)'
- 'Intermediate (use terminal sometimes)'
- 'Advanced (terminal is my primary tool)'
```

#### b. User Research Insight

```yaml
name: 'User Research Insight'
description: 'Share findings from user research, usability testing, or user interviews'
labels:
- 'area/ux'
- 'type/user-research'
body:
- type: textarea
id: methodology
attributes:
label: 'Research method'
description: 'How did you gather this insight? (e.g., usability test, user interview, survey, heuristic evaluation)'
validations:
required: true
- type: textarea
id: findings
attributes:
label: 'Key findings'
description: 'Summarize the main insights from your research.'
validations:
required: true
- type: textarea
id: recommendations
attributes:
label: 'Recommendations'
description: 'What changes would you recommend based on these findings?'
- type: textarea
id: evidence
attributes:
label: 'Supporting evidence'
description: 'Include data, quotes, recordings, or other evidence.'
```

### 2. New labels for non-engineer contributions

| Label | Description | Purpose |
|-------|-------------|---------|
| `role/non-engineer` | Issues that don't require coding skills | Discovery filter for non-engineers |
| `role/ux-designer` | Needs UX/design expertise | Attract design contributors |
| `role/product` | Product strategy or prioritization input welcome | Attract PM contributors |
| `type/ux-feedback` | UX improvement feedback | Categorize UX feedback |
| `type/user-research` | User research findings | Categorize research |
| `good-first-issue-non-code` | Entry-level tasks not requiring code | Onboarding for non-engineers |

### 3. Add non-engineer section to CONTRIBUTING.md

Add a new section: **"Non-code contribution process"** covering:

- **UX Review**: How to conduct and submit heuristic evaluations of Gemini CLI
- **User Research**: How to conduct user tests and share findings
- **Documentation Review**: How to review docs from a user perspective (not just typo fixes)
- **Accessibility Audit**: How to evaluate and report accessibility issues
- **Onboarding Feedback**: How new users can document their first-time experience as valuable data

Example addition:

```markdown
## Non-code contribution process

Not a developer? You can still make a significant impact! Non-code contributions
are essential for making Gemini CLI usable and accessible to everyone.

### UX feedback

The best UX insights come from real usage. If you encounter confusing
interactions, unclear error messages, or awkward workflows:

1. Use the **UX Feedback** issue template.
2. Include screenshots or terminal recordings when possible.
3. Describe your experience level — beginner perspectives are especially valuable.

### User research

If you have UX research skills, we welcome structured findings:

1. Use the **User Research Insight** issue template.
2. Describe your methodology (usability test, interview, heuristic evaluation, etc.).
3. Include supporting evidence (quotes, data, recordings).

### Documentation review (user perspective)

Read our docs as a user, not an editor:

1. Follow the quickstart guide from scratch.
2. Document where you got stuck or confused.
3. File a UX Feedback issue with your findings.

### First-time experience report

Your first hour with Gemini CLI is uniquely valuable data that experienced
users can never reproduce. We encourage new users to:

1. Record their first session (terminal recording or notes).
2. Note every moment of confusion or delight.
3. Submit as a UX Feedback issue with the `good-first-issue-non-code` label.
```

### 4. Structured UX review process for releases

The current `release-confidence.md` acknowledges that "automated tests cannot catch everything, especially UX issues" but relies solely on maintainer dogfooding.

**Proposal**: Add a community UX review step to the release process:

- Before `preview` → `stable` promotion, invite community UX reviewers to test the Critical User Journeys (CUJs)
- Create a `ux-reviewer` GitHub team for community members interested in UX review
- Provide a lightweight UX review checklist (based on existing CUJ checklist, but focused on usability rather than functionality)

### 5. Non-engineer friendly areas to highlight

Based on codebase analysis, these existing areas could benefit from non-engineer input today (with proper labeling):

| Area | Contribution type | Skills needed |
|------|-------------------|---------------|
| Error messages in `packages/core/src/utils/errors.ts` | Review clarity and helpfulness | Writing, empathy |
| Onboarding flow in `docs/get-started/` | Test and improve first-time experience | User perspective |
| Keyboard shortcuts in `docs/reference/keyboard-shortcuts.md` | Evaluate discoverability | UX evaluation |
| CLI output formatting | Review readability of tool outputs | Visual design |
| `docs/resources/faq.md` | Identify missing questions from user perspective | User empathy |
| Themes in `packages/cli/src/config/` | Design new color themes | Visual design |

## Expected impact

- **Short-term**: More diverse feedback improves UX quality, supporting the CSAT goal
- **Medium-term**: Non-engineer contributors bring perspectives that broaden Gemini CLI's appeal beyond power users
- **Long-term**: A more inclusive OSS community is more sustainable and produces a better product

## Additional context

This proposal is informed by analysis of:
- The full Gemini CLI codebase structure and contribution infrastructure
- ROADMAP.md guiding principles and focus areas
- Current Issue template and label structure
- The competitive landscape (15+ AI CLI tools, Anthropic's 54% coding market share)
- Market data showing the need for UX differentiation

The AI CLI tools market is in rapid growth. The projects that build the most inclusive contributor communities will have a structural advantage in product quality and user adoption.