Contributing document is unwieldy
Problem/Opportunity Statement
contributing.md
is:
- Not short (3000 words).
- Written for a mix of several audiences.
- Some information that is important for newer project contributors (e.g. MR quality checklist) is buried underneath information that is most relevant to existing project maintainers (e.g. issue triage process).
What would success / a fix look like?
- Split this up into several documents, aligned according to "who cares about this information, and in which situation".
- Update navigation pane so that folks can find what they need.
- Update links accordingly throughout the docs and codebase.
Appendix: Structure of current contributing doc
# Contributing to Exosphere
(2 paragraphs)
## Quick Start for New Contributors
(3 paragraphs, long bulleted list)
## Issue Triage Process
### Who and When
(3 paragraphs)
### Deduplication
(3 paragraphs)
### Resolving Disagreements
(1 paragraph)
### Quick Triage Checklist
(bulleted list)
### Detailed Triage Checklist
#### Description
(2 paragraphs)
#### Weight
(3 paragraphs, bulleted list)
#### Labels
(1 paragraph)
##### Label: Type
(1 paragraph, bulleted list)
##### Label: Severity
(2 paragaphs, numbered list with nested sub-lists)
##### Label: Priority
(2 paragraphs, numbered list)
##### Label: "Triaged"
(1 paragraph)
## Core Contributor Onboarding
(1 paragraph)
### Development Environment Setup
(1 paragraph, long nested bulleted list)
### Design Review Process
(2 paragraphs)
### Submitting a Contribution
(4 paragraphs)
### MR Quality Checklist
(1 paragraph)
#### Administrative
(nested bulleted list)
#### Quality and Technical Debt
(1 paragraph, bulleted list)
#### Functional
(nested bulleted list)
#### Documentation
(bulleted list)
(1 paragraph)
## Continuous Integration
(1 paragraph, bulleted list, code block)
### Enabling CI On Your Fork
(3 paragraphs, numbered list)
### End-to-end browser tests
(4ish paragraphs, numbered list)
#### Special Branch Behavior
(3 paragraphs)
## Architecture Decisions
(2 short paragraphs)