Commit Rule 정하기

[byundojin]

의견 있으면 여기 제시해 주세요.

[onee-only]

[RFC{문서 번호}] {섹션 번호} - {제목} 어떤가요?

[byundojin]

좋은 것 같습니다. 문서 수정에 경우는 어떻게 할까요?

[onee-only]

좋은 것 같습니다. 문서 수정에 경우는 어떻게 할까요?

[RFC{문서 번호}] {섹션 번호} - {수정사항} 이렇게 하는 것도 괜찮을 것 같은데 이 부분이랑 헷갈릴 수도 있을 것 같아요.

[byundojin]

아니면 tag를 사용하는 것은 어떨까요?

[onee-only]

아니면 tag를 사용하는 것은 어떨까요?

@byundojin 예시 부탁드립니다!

아니면 [RFC{문서 번호}] {섹션 번호} - {수정사항} 아니면 문서 생성/수정/삭제 모두 이 포맷으로 가는 건 어떨까요?

예를 들어 문서 1번의 1.1 섹션을 추가한다면 [RFC1] 1.1 - Example Title 섹션 추가 와 같은 포맷이 될 것 같아요.

[byundojin]

Label사용을 의미하는 것 이였는데 잘못된 단어를 사용하였습니다. 수정사항은 간단한 수정 내용만 기제하고 흔히 나오는 수정은 Label로 처리하는 것이 좋을 것 같습니다.

예시) [RFC-1945] 1.1 - 문서 형식 수정 | Label - 수정 [RFC-1945] 1.1 - 오타 수정 | Label - 수정, 오타

또한 수정 번호를 기제하는 것도 좋을 것 같지만, 불필요하게 작업을 늘리는 것 같아 검토가 필요해 보입니다.

[onee-only]

@byundojin 레이블 같은 건 PR에 지원되는 태그를 사용하는 선에서 잘 정리 할 수 있을 것 같습니다. 커밋 히스토리를 어느 용도로 사용하느냐에 따라 다르겠지만 특별한 목적이 없는 경우에는 레이블을 관리하는 책임은 PR로 넘겨도 될 것 같아요.

[byundojin]

아 죄송합니다. 전체적인 맥락을 PR로 잡고 있었네요. 그렇다면 평균적으로 PR하나에 한개의 RFC만 작성하니 [RFC번호]는 생략하여도 충분히 유추할 수 있을 것 같아요. [섹션 번호]{작성/수정/삭제} - 세부 로 표기하고 작성과 삭제시 제목을 세부에 작성하는 것은 어떨까요.

예시) [1.1]작성 - Introduction [1.1]수정 - 오타 수정 [1.1]삭제 - Introduction

[onee-only]

@byundojin RFC 번호는 커밋을 PR에서만 확인 하는 것이 아닌 전체 커밋 히스토리에서 쉽게 구분 할 의도로 추가하였습니다!

[섹션 번호]{작성/수정/삭제} - 세부 로 표기하고 작성과 삭제시 제목을 세부에 작성하는 것은 어떨까요.

커밋 메시지의 일관성이 떨어져 처음 보는 사람이 읽었을 때 잘 읽히지 않을 수도 있을 것 같다는 생각이 듭니다. 그 상황이 생길지는 잘 모르겠긴 합니다만 😅 , 제 생각에는 단순하고 구조화된 템플릿을 사용하는 게 읽는 사람을 잘 고려할 수 있다고 생각해요..

그런 의미에서 하나 슬쩍 제시하자면 [{RFC번호 (사용하게 된다면)}] {섹션 번호} - {제목}: {세부사항 (없으면 표시 X}도 있을 것 같아요. 너무 verbose해지는 감이 없지 않아 있는데 의견 하나 던지는 생각으로 제시해 봅니다.

[byundojin]

@onee-only 의견 잘 알겠습니다. 하지만 일관성이 떨어진다는 부분을 잘 이해할 수 없습니다. 이 부분에 대해 설명이 필요할 것 같습니다.

또한 제시된 의견 잘 봤습니다. 전체 커밋 히스토리에 대해 미쳐 생각하지 못하였는데 좋은 의견이라 생각합니다. 다만 너무 장황한 감이 없지 않습니다. 제목을 제거하고 세부를 내리는 형태는 어떨까요?

예시)
[RFC-1945] 1.1- 수정(가독성을 위한 작업 표시)
- 오타 수정 : 만니 -> 많이

저렇게 밑으로 내리면 작게 표시되는 것으로 알고있습니다.

검토 후 의견 말해주세요.

[byundojin]

또한 다른 이야기지만, PR을 close후 같은 RFC의 대해 새 PR을 생성하는 것 보다. 기존의 PR을 다시 open하는 것이 RFC에 히스토리 추적에 용이할 것 같습니다. RFC문서당 하나의 PR을 두는 형식으로요.

PR방식이 변경된다면 기존 방식에 변경이 필요할 수 있으니 신중한 논의가 필요할 것 같습니다.

[onee-only]

@onee-only 의견 잘 알겠습니다. 하지만 일관성이 떨어진다는 부분을 잘 이해할 수 없습니다. 이 부분에 대해 설명이 필요할 것 같습니다.

한 공간에 어떨 때는 섹션 제목이 나오고, 어떨 땐 작업 세부 사항이 나온다면 읽는 사람 입장에선 혼란스러울 수 있다고 생각했습니다.

예시)
[RFC-1945] 1.1- 수정(가독성을 위한 작업 표시)
- 오타 수정 : 만니 -> 많이

저렇게 밑으로 내리면 작게 표시되는 것으로 알고있습니다.

검토 후 의견 말해주세요.

@byundojin 좋은 의견입니다! 세부 사항에 대한 설명이 길어질 때도 커밋 본문으로 들어가니 커밋 히스토리가 한눈에 보기 좋을 것 같습니다!

[onee-only]

또한 다른 이야기지만, PR을 close후 같은 RFC의 대해 새 PR을 생성하는 것 보다. 기존의 PR을 다시 open하는 것이 RFC에 히스토리 추적에 용이할 것 같습니다. RFC문서당 하나의 PR을 두는 형식으로요.

오픈소스 프로젝트이다 보니 외부 컨트리뷰터가 기여 할 일도 있을 것 같습니다. 그럴 땐 기존 PR에 대한 권한이 없으니 따로 PR을 여는 방식으로 유지 하는 게 좋을 것 같아 보입니다.

[byundojin]

한 공간에 어떨 때는 섹션 제목이 나오고, 어떨 땐 작업 세부 사항이 나온다면 읽는 사람 입장에선 혼란스러울 수 있다고 생각했습니다.

무슨 의미인지 알았습니다. 의도는 모든 commit message의 형식을 같게 하여 일광성 및 가독성을 챙기기 위함이였습니다.

오픈소스 프로젝트이다 보니 외부 컨트리뷰터가 기여 할 일도 있을 것 같습니다. 그럴 땐 기존 PR에 대한 권한이 없으니 따로 PR을 여는 방식으로 유지 하는 게 좋을 것 같아 보입니다.

외부 컨트리뷰터에 대한 생각을 미쳐 하지 못했습니다. 이에 대해선 기존의 방식을 유지하는 것이 좋을 것 같습니다.

[byundojin]

commit rule의 대한 의논이 어느 정도 진행되었다 생각합니다. RFC문서 작성을 시작하며, 기타 부수적인 상황은 진행 도중 발생하면 그때 의논하는 걸로 합시다.