2. SEP(사양 개선 제안) 가이드라인

SEP란 무엇인가

SEP(Specification Enhancement Proposal)는 iFay 사양 변경에 대한 공식적인 제안 프로세스입니다. iFay 사양에 대한 모든 실질적인 수정 — 새로운 모듈 추가, 프로토콜 동작 변경, iFay Profile 데이터 모델 조정 등 — 은 SEP 프로세스를 통해 진행되어야 합니다.

SEP가 필요한 이유

iFay는 다중 벤더 구현의 개방형 표준 생태계이며, 사양의 모든 변경은 모든 구현자에게 영향을 미칠 수 있습니다. SEP 프로세스는 사양의 발전이 질서 있고, 투명하며, 추적 가능하도록 보장하여 모든 이해관계자가 토론과 검토에 참여할 기회를 제공합니다.

SEP 생명주기

SEP는 제안부터 최종 구현까지 다음 단계를 거칩니다:

1. Draft(초안)

제안자는 GitHub에서 표준 템플릿을 사용하여 SEP Issue를 생성하고, 동기, 제안하는 해결책, 영향을 기술합니다. Draft 단계의 SEP는 불완전할 수 있지만, 커뮤니티가 제안의 의도를 이해할 수 있는 충분한 정보를 포함해야 합니다.

2. Discussion(토론)

SEP는 최소 14일간의 공개 토론 기간에 들어갑니다. 이 기간 동안:

• 커뮤니티 구성원과 관련 워킹 그룹이 제안에 대해 토론합니다
• 제안자는 피드백을 바탕으로 제안을 수정하고 개선합니다
• 관련 하위 프로젝트의 메인테이너가 각자의 도메인에 대한 영향을 평가합니다

3. Review(검토)

토론 기간이 종료된 후, 코어 메인테이너가 SEP에 대한 공식 검토를 수행합니다. 검토 중 제안자에게 추가 수정이나 보완을 요청할 수 있습니다. 예를 들어:

• 하위 호환성 분석 추가
• iFACTS 테스트 영향 평가 완료
• 대안적 접근 방식의 비교 분석 제공

4. Accepted / Rejected(승인 / 거부)

코어 메인테이너는 투표를 통해 SEP의 최종 결과를 결정합니다:

• Accepted(승인): SEP가 승인되어 구현 단계로 이동합니다
• Rejected(거부): SEP가 거부되며, 거부 사유가 기록됩니다. 제안자는 피드백을 바탕으로 수정하여 재제출할 수 있습니다

5. Implemented(구현 완료)

승인된 SEP는 구현 단계에 들어갑니다. 구현 작업은 제안자 또는 다른 기여자가 수행할 수 있습니다. 구현 중:

• 관련 사양 문서를 업데이트해야 합니다
• 참조 코드를 구현해야 합니다(해당하는 경우)
• iFACTS 테스트 케이스를 작성하거나 업데이트해야 합니다

6. Final(최종)

구현이 완료되고 검토를 통과한 후, SEP는 최종 상태에 들어갑니다. 이 시점에서:

• 사양 문서가 업데이트되어 있습니다
• iFACTS 테스트 스위트가 그에 맞게 업데이트되어 있습니다
• 관련 문서와 가이드가 업데이트되어 있습니다

SEP 템플릿

SEP를 제출할 때 다음 내용을 포함해 주십시오:

• 제목: 제안에 대한 간결한 설명
• 동기: 이 변경이 왜 필요한가? 어떤 문제를 해결하는가?
• 상세 설계: 제안의 기술적 세부 사항과 구현 계획
• 하위 호환성: 기존 사양 및 구현에 대한 영향 분석
• iFACTS 영향: 추가하거나 수정해야 하는 컴플라이언스 테스트
• 대안: 검토한 다른 접근 방식과 그 비교 장단점

SEP를 제출할 수 있는 사람

누구나 SEP를 제출할 수 있습니다. 코어 메인테이너, 메인테이너, 기여자, 또는 iFay 생태계의 사용자이든, 사양의 개선이 필요하다고 판단되면 제안을 제출하시기 바랍니다.

특별 참고사항

프로토콜 변경을 수반하는 SEP에는 특별한 주의가 필요합니다. iFay의 각 프로토콜(Faying, Telepathy, ICP, CAP, DTP, SSP)은 독립적인 하위 프로젝트에 대응하므로, 관련 프로토콜의 메인테이너가 검토에 참여해야 합니다. 예를 들어, Control Authority Protocol(CAP)의 동작을 수정하는 SEP는 WG-Protocols 워킹 그룹의 메인테이너가 Device Driver Hub 및 FayGer 런타임 등 관련 모듈에 대한 영향을 평가해야 합니다.