FSWP Core Contributor은(는) 무엇을 하나요?
기본 (항상 적용): fswp-developer/references/lean-coding.md (적게 작성하고, 재사용 우선), fswp-developer/references/coding-standards.md (코딩 표준, 문서, i18n, 접근성), fswp-security-engineer (입력, 출력, 인가).
여기의 워크플로 사실은 2026-09-28 기준 Core Contributor Handbook을 확인한 것입니다. 코어 프로세스는 변경될 수 있습니다. 시간에 민감한 내용은 조언 전에 fswp-developer/references/official-docs.md를 확인하세요. 여기서는 아무것도 제출하지 않습니다: 사용자가 직접 티켓을 제출하고 풀 리퀘스트를 엽니다 (GitHub 자동화는 예약되어 있으며 fswp-developer/references/github-foundation.md 참조).
변경 사항을 먼저 라우팅하세요
| 변경 사항이 다음에 해당하는 경우 | 이동 대상 |
|---|---|
| 취약점 | Core 핸드북에 연결된 비공개 보안 프로세스. 절대 공개 티켓이나 PR이 아닙니다. 중단하고 그렇게 말하세요. |
| PHP, 관리자 화면, API, 테스트, 대부분의 코어 코드 | Trac 티켓 및 WordPress/wordpress-develop에 대한 패치 또는 풀 리퀘스트 (이 스킬) |
| 블록 에디터 (Gutenberg 패키지, 편집기 UI, 사이트 에디터) | WordPress/gutenberg의 이슈 및 풀 리퀘스트; 코어는 해당 저장소에서 업데이트를 받습니다. 해당 저장소의 기여 가이드를 읽으세요. |
| 플러그인 또는 테마 버그 | 코어가 아님; fswp-maintainer를 사용하고 해당 프로젝트에 보고하세요 |
| 문서 | 해당 핸드북의 문서 팀 프로세스 |
티켓 우선
- Trac (https://core.trac.wordpress.org/)에서 증상을 검색하세요. 티켓 기록과 패치를 읽으세요.
- 티켓이 없으면 초안을 작성하세요: 정확한 제목, WordPress/PHP 버전, 재현 단계, 예상 결과 vs 실제 결과, 그리고 이것이 결함(버그)인지 개선인지 이유를 포함하세요. 사용자가 올바른 구성 요소 아래에 제출합니다.
- 티켓의 워크플로 키워드(예: 단위 테스트 요청)를 확인하고 따르세요.
환경
일반 사이트가 아닌 개발 체크아웃을 사용하세요:
WordPress/wordpress-develop를 클론하세요 (Subversion으로 관리되는 표준 저장소의 Git 미러).- Docker와 Node가 표준 워크플로에 필요합니다. 체크아웃 루트에서:
npm install,npm run build:dev,npm run env:start,npm run env:install. - PHP 테스트는
npm run test:php로 실행하세요. PHPUnit 인수는 이중 대시 뒤에 전달합니다(예:-- --group formatting).@ticket태그가 있는 테스트는 티켓 번호별로 그룹으로 실행됩니다. 멀티사이트는 자체 구성이 있습니다(-c tests/phpunit/multisite.xml); AJAX 테스트는--group ajax로 실행됩니다. - Docker 외 워크플로(Composer, PHPUnit PHAR)도 가능합니다; 핸드북의 PHPUnit 페이지를 참조하세요.
변경 사항 작성
- trunk에서 브랜치를 만드세요; 브랜치 이름은 티켓 번호를 포함하세요(예:
12345-short-description). 변경 사항은 하나의 티켓에 집중하세요. - 코딩 표준: WordPress PHP, JS, CSS, HTML 표준 (Yoda 조건, 탭, 간격, 이스케이프/샌타이징 규칙 포함). 변경된 파일에 PHPCS를 실행하세요.
- 인라인 문서: 코어 스타일의 새 함수, 훅, 클래스에 대한 PHPDoc,
@since는 티켓 마일스톤이 명시한 버전으로 설정하세요. - 하위 호환성: 코어는 공개 동작을 거의 깨뜨리지 않습니다. 제거 대신 폐기(
_deprecated_function()등)하세요; 필터와 액션은 안정적으로 유지하세요; 함수 시그니처를 보존하세요. - 테스트:
@ticket태그가 있는 PHPUnit 테스트를 추가하거나 업데이트하여 변경 전에 실패하고 변경 후에 통과하도록 하세요. 테스트 없는 버그 패치는 일반적으로 테스트 추가를 요청받습니다. - 보안 및 성능: 모든 WordPress 코드와 동일한 규칙(
fswp-security-engineer,fswp-performance-engineer)을 따르며, 더 엄격한 기준이 적용됩니다. - 관련 없는 서식 변경이나 리팩터링을 포함하지 마세요.
제출 (사용자가 수행)
- 티켓 번호로 이름이 지정된
.diff파일을 Trac 티켓에 첨부하거나, 티켓을 참조하는WordPress/wordpress-develop에 대한 풀 리퀘스트를 여세요. 풀 리퀘스트는 리뷰에 사용되며, GitHub에서 병합되지 않습니다(커미터가 표준 저장소를 통해 커밋하기 때문). - 티켓 코멘트를 작성하세요: 패치가 무엇을 하는지, 어떻게 테스트했는지, 테스터가 따를 수 있는 단계, 그리고 열려 있는 질문.
references/ticket-comment-template.md를 사용하여 사용자를 위해 초안을 작성하세요. - 리뷰, 변경 요청, 느린 사이클을 예상하세요. 티켓에 응답하고, 패치를 업데이트하고, trunk에 리베이스 상태를 유지하세요.
인계 전 확인
Core 체크리스트로 fswp-qa-engineer를 실행하세요: 재현이 변경 전에는 실패하고 변경 후에는 통과하며, 관련 테스트 그룹이 통과하고, 코딩 표준이 변경된 줄에서 깨끗하며, 문서가 있고, BC가 유지됩니다.