기본 규칙 설정

[duaghk]

간단한 규칙을 만들었으면 좋겠습니다.

1. 기본적으론 서로 지식공유의 장이 되었으면 좋겠습니다. 그러다보니, 단순 코드 복붙은 지양하는 방향으로 했으면 좋겠습니다.
2. 라이센스 적용도 좋을 것 같네요. CC 5.0같은 것으로, 서로의 코드는 보호가 되었으면 좋겠습니다.
3. 이외에도 반영했으면 싶은 사항은 알려주세요 :)

[swiri021]

일단 전부 owner권한을 가지는건 힘들것 같고요. Member로 하되 권한을 정리하는 쪽으로 가는게 맞을거 같네요. 그리고 repo는 어느정도 룰이 있는게 맞을거 같고요. 간단하게 readme는 꼭 만들어야 한다던가 main branch는 direct push는 못하게 한다던가. 그리고 코드리뷰 타임도 있었으면 좋겠네요

[duaghk]

중요한 의견이죠... owner 부여는... 팀 매니저 등으로 정하면 좋을것 같긴 하네요. repo는 말씀하신대로 메인브랜치는 직접 push는 안되는게 좋죠. 코드리뷰는... 각 팀별로 자율성을 부여하는것도 좋을 것 같고요.

[lioseo]

아직은.. 아무것도 정해진 부분은 없지만 나온 의견들을 조금씩 정리하면 어떤가해서이고 앞으로 단톡에서 말씀주신 것처럼 기획이 더 필요한 부분인거 같기는 합니다.

repo 관리 측면에서 볼 때, 현재까지 나온 아이디어들(?) 혹은 앞으로 토의 내용 정리도 doc repo로 만들고 markdown 이용하면서 정리해도 좋을 것 같다고 생각인데
이부분은 전체 혹은 repo별로 일지..
그리고 지금처럼 깃헙에서 논의하거나 아니면 나중에 다른 소통채널(슬랙? 카톡?)일지 소통이 잘 이루어지는 부분으로 정해지는 것도 좋은거 같습니다. 저도 코드리뷰 타임 좋은 것 같습니다.

[Myno-Jeong]

안녕하세요. 만나서 반갑습니다. 먼저 이러한 장을 마련해주신 분들께 진심으로 감사드립니다.
앞서, 기본 규칙 들에 대해 논의를 해야하는 부분이 있는 걸로 알고 있습니다.
우선, 본 깃헙을 활성하하기 이전, 코드 리뷰 등과 같은 규칙을 정하면 좋겠습니다.
코드 리뷰와 관련해서 한 가지 의견을 드리면, 일관적인 코드 작성 및 리뷰를 위해서 prettier / autopep8과 같은 코드 포멧터와 관련된 규칙들을 먼저 정하면 좋을 듯 합니다. 그 이유는 참여하시는 모든 분들의 코딩 스타일이 다르실 거라 생각이 되기 때문입니다.

각자 선호하시는 코드 포메터 및 그와 관련된 내용을 공유하면 도움이 많이 될 것 같습니다.

감사합니다. 오늘도 활기찬 월요일 보내시길 바랍니다!

[Myno-Jeong]

저도 google code style을 지향하고 있습니다.
저의 경우에는, code editor는 VScode를 사요하고 있습니다.
python에 대한 Formatter는 autopep8을 사용하고 있고, python script 이외의 파일들에 대해서는 prettier를 사용하고 있습니다.
이러한 부분들을 취합해보는 것도 앞으로 규칙을 설정하는데 도움이 많이 될 것 같습니다.
처음 세팅을 하시는 분들께도 유용할 거라 생각합니다. 저 같은 경우에는 이런 부분을 설명해주신 분들이 없어서 구글링을 통한 삽질을 많이 했지만요 ㅎㅎ

[duaghk]

저랑 같으시네요. 다만 전 원래 formatter는 pylint를 사용했는데, vs code에서 deprecated 되었다고 해서... black를 보고있긴 합니다. 다른건 저도 prettier를 쓰고 있긴 하네요. 사족으로 저도 혼자서 삽질해서 배운 케이스라... 이런게 있다면 도움이 되겠죠

[swiri021]

음... 개인적으로 org레벨에서 linter를 통일할 필요까지는 없어보이긴 하는데, 각자 repo에서 설정한 linter로 운용하시면 되지 않을까 싶네요. 저는 black을 주로 씁니다.

[duaghk]

아 linter는 repo level에서 통일하는 것으로 하죠!

[Myno-Jeong]

repo level에서 linter를 설정하는게 바람직한 걸로 판단됩니다. 다만, repo별로 너무 중구난방할 것 같아서, org 레벨에서 어느 정도 가이드라인이 있으면 좋을 것 같아 말씀 드렸습니다!!

[duaghk]

음... 기본적으로 리포에 명시해야 할 사항을 몇 가지 적어봤는데, 혹시 추가해야 할 것 있으면 알려주시면 좋겠습니다.

• README 권장 사항

1. Repo purpose
2. License: Creative commons 5.0(권장)
3. Code style: Google code style(repo 에서 결정)
4. Branching strategy: ...?

[Myno-Jeong]

Branch strategy와 더불어 git commit guide도 설정해놓으면 좋을 것 같습니다. 물론 이 부분도 repo level에서 설정하는게 좋겠지만, 그래도 어느 정도의 통일성을 유지하기 위한 가이드라인을 만들어 두는 것이 좋지 않을까 생각합니다!

[swiri021]

네, git branch 가이드라인도 커뮤니티에 announcement로 올리는게 좋을거 같네요 ! 이런걸 Devops 하시는 분이 맡으시면서 리뷰도 해주셨으면 좋겠어요.

[Myno-Jeong]

Devops하시는 분이 계실지 잘 모르겠네요. BI하시는 분들이 대부분이실 것 같아서ㅠㅠㅎㅎ
branch 가이드라인에 대해서도 같이 논의해보며 좋을 것 같네요.
우선, 제가 생각하는 branch policy는 다음과 같습니다:

1. develop branch: 개발 진행 메인으로 활용. 단일 branch로 유지 & Commit 순서대로만 관리가 가능
2. Feature branch: develop branch에서 분기 후 개발 작업 진행 branch (ex. feature/development_theme-> 개발 완료 후 develop branch에 merge 후 삭제
3. bugfix branch: develop branch에서 분기 후 버그 개선 작업 진행 branch (ex. bugfix/bugfix_YYMMDD) -> 버그 개선 작업 완료 후 develop branch에 merge 후 삭제
4. Release branch: develop branch로부터 분기, 각 Release version에 대한 branch를 신규 생성(ex. release/3.0.0)하여 활용, maintenance는 각 주.부 버전의 최종 수버전만 진행. 배포시 Release branch와 Tag를 통해 버전 관리
5. master(main) branch: 소스코드의 안정화된 형상 유지용으로 활용

이 정도가 되겠네요. 다른 분들도 편하게 의견 제시해주시면 감사하겠습니다.

[swiri021]

말씀하신 Git workflow 가장 좋긴하지요. 근데 사용해보니, release branch는 잘 사용하진 않게 되더라고요, 나머지 main, dev, feature, bug branch들을 유지하되 bi에서는 추가적으로 test branch를 사용하는게 좋을거 같아요. 그리고 어느정도 repo의 서비스가 유지되고 더이상 신규 업데이트가 없는 경우는 trunk based가 좋아보여요. 여기에 맞물리는게 semantic versioning(vX.Y.Z)기법인데, 저는 nextflow 파이프라인이나 bi에 맞게끔 수정해서 버져닝을 맞췄습니다. 그래서, 최종적인 branch들은 예로 main, test, dev/v1.2.3, feature/new-input-function, bugfix/loading-screen-fix 이런식르로 하는건 어떨까 싶네요. 물론 repo는 자율적으로 이걸 따르는게 좋을거 같고요. 그리고 test는 항상 dev branch로 부터 MR을 통해야 하고 test는 optional로 infrastructure(e.g AWS, nextflow pipeline) 할때만 사용하면 되지 않나싶네요. main은 항상 dev나 test branch를 통해야 하고 모든 direct push는 특별한 케이스가 아니면 허용하지 않으며 모든 MR은 항상 1명 이상의 리뷰어가 지정되면 좋을것 같네요.

[Myno-Jeong]

선생님 말씀에 동의합니다. 저는 featrue branch에서 모든 테스트를 완료한 후에 dev branch에 merge를 했어서 test branch에 대한 생각은 안해봤네요. 물론 dev branch merge 후 통합 테스트도 진행했지만, 통합 테스트를 진행하는 동안 발생하는 이슈들에 대응하기 위해서는 test branch도 필요해보입니다. (저도 dev branch에서 직접적으로 코드를 수정해서 push하는 것은 지양하는 입장입니다.)
또한, 말씀하신 것처럼 semantic versioning에 대해서도 고려해야 하겠지만, 디테일한 부분은 각 프로젝트 내에서 정립하는 것이 좋아보입니다. 처음 접하시는 분들도 계실 수도 있기에 대략적인 버전 명세 방법은 org 레벨에서 어느정도 가이드를 잡아주거나 관련 자료를 보여주는게 좋을 듯 싶네요 ㅎㅎ

추가적으로 CI / CD 정책은 git에서 논할 주제는 아닌 것 같아 생략하는 것이 좋을 것 같습니다.