원문: https://github.com/facebook/astryx/wiki/Contributing · 번역 기준: 2026-09-03
Astryx는 정확성(correctness), 일관성, LLM codegen 품질에 대해 강한 견해를 가진 디자인 시스템입니다. 이 문서는 기여가 어떻게 이루어지는지, 우리가 무엇을 소유하는지, 그리고 여러분이 우리에게 무엇을 기대할 수 있는지를 설명합니다.
기본 원칙은 이렇습니다: 들어오는 것에는 더 엄격하게, 사용되는 방식에는 덜 엄격하게. 기여 프로세스는 높은 기준과 실질적인 게이트를 갖고 있습니다. 하지만 일단 무언가가 시스템에 들어오면, 소비자가 그것을 어떻게 사용하는지는 우리가 지시하지 않습니다 — 그 유연성이 핵심입니다.
전체 그림은 Astryx Philosophy를 읽어보세요. 이를 이해하면 더 나은 RFC를 작성하고, 우리가 거절할 가능성이 높은 제안을 피하는 데 도움이 됩니다.
Astryx에 기여한다는 것은 컴포넌트가 아니라 시스템에 기여하는 것입니다. 일단 무언가가 들어오면, 그것은 기여자의 원래 의도가 아니라 시스템의 일관성(coherence)에 속합니다. 시스템이 진화함에 따라 우리는 기여자의 동의 없이도 breaking change를 포함한 조정을 수행합니다.
API 결정은 취향의 문제가 아닙니다. 모든 분쟁은 vibe testing과 문서화된 컨벤션 준수를 통해 해결됩니다 — 객관적이고, 재현 가능하며, 문서화되어 있습니다.
시스템 변경에 대한 최종 결정 권한은 Astryx 팀이 갖습니다. 많은 소비자를 섬기는 디자인 시스템에는 부분이 아니라 전체에 책임을 지는 누군가가 필요합니다. 여기의 프로세스들 — RFC, vibe testing, 문서화된 컨벤션 — 은 모든 결정이 여러분이 관여할 수 있는 명확한 근거를 갖도록 존재합니다. 우리는 기여자들이 증거로 뒷받침된 강한 논거를 가져오기를 바라며, 그 논거를 진지하게 받아들입니다. 하지만 시스템에는 어떤 단일 기여도 일부만 볼 수 있는 장기적인 방향이 있으며, 어떤 기능에 대한 증거가 실재하더라도 때로는 답이 "아직은 아니다" 또는 "이 방식은 아니다"일 수 있습니다. 우리가 거절하거나 방향을 바꿀 때는, 여러분이 반박할 수 있는 용어로 이유를 설명하겠습니다 — 그리고 여러분의 반론이 더 강하다면 우리는 방향을 바꿀 것입니다. 이 프로세스는 시스템의 일관성을 유지하면서 커뮤니티에 책임을 지는 방법입니다.
먼저 이슈를 열어 해당 동작이 버그임을 확인한 뒤 PR을 제출하세요. 테스트, 재현 케이스, 또는 문서화된 수동 검증 단계(접근성 수정의 경우 AT와 브라우저 조합 포함)를 포함하세요. PR은 범위를 좁게 유지하세요.
Astryx 패키지의 컴포넌트는 전적으로 팀 소유입니다. 새 컴포넌트를 추가하는 경로는 다음과 같습니다: