미팅

1. 중간 미팅을 너무 자주 진행한다고 느끼는지 @정주연 : 지금 정도 괜찮은 것 같다. 다만 그냥 일정 확인용을 위한 미팅은 안했으면 좋겠다!
2. 미팅 시간이 정해져 있는게 좋은지 @정주연 오히려 부담이 될 수 있으니 필요에 의해서 해요!
3. 채팅 알람 추가하기 @이동재 게더 및 슬랙 채팅에 알람을 설정해서 원활한 소통이 가능하도록 해요.

PR

1. approve 여부에 따른 merge 제한

   장점: 코드 리뷰 강제, 서로의 진행사항 파악

   단점: merge가 느려서 막힌다

   @정주연 PR 병목현상이 생긴다 → 코드 리뷰 시간을 따로 정해놓게 해야한다. 혹은 approve 제한은 열어두고 특정 요일에는 코드리뷰를 하도록 하자.

   @혜원 강 다음주나 다다음주부터 얘기해도 좋을 것 같다(지금은 피쳐가 지우는데 정신이 없다)

   @이동재 @JIHYUN KIM 혜원님 의견에 동의

2. reviewer 을 명시할 것인지 @정주연 코드리뷰 룰을 정한 뒤 규칙을 함께 정하자

3. 이 정도면 PR 내용이 적절한지

4. PR 타이틀 형식이 각자다름 → Git PR 템플릿 수정 필요 @정주연 [FE] 기능 이름 등..

   @이동재 FE는 태그로 붙혔다.

   @JIHYUN KIM 커밋을 상세하게 적어서(Intent) PR 내용에는 크게 집중할 필요 없을 것 같다.

   @이동재 코드리뷰 룰이 정해지면 내용 형식 개선하면 될 것 같다

   ⇒ 템플릿 수정 (title: "[커밋 컨벤션의 타입] 제목")

5. Conflict가 났을 땐?

   PR 날리기 전에 향하고 있는 브랜치에서 먼저 pull을 한다. 해결할 코드가 이해가 안된다면 컨플릭트난 코드를 짠 사람에게 가서 같이 해결하기

6. PR에 코드리뷰는 어떤 식으로 진행할지

   @이동재 나중에 코드 리뷰를 본격적으로 할 때 정하자.

7. PR 작성후 브랜치 삭제 진행할지 @JIHYUN KIM PR 후 merge가 완료되면 브랜치 삭제하기

   → Approve git 컨벤션에 반영함

업무 분배

• 백엔드에서 먼저 작업이 끝나고 프론트는 할일이 남아있는게 마음이 걸렸다. 이럴때는 어떻게 해야할까?

  @정주연 피곤하면 일단 쉬자 제발 쉬자! 정말 뭔가 하고싶다면 다른 사람의 코드 리뷰를 진행해보자 @이동재 closed PR에 리뷰를 남겼다고 가정했을 때, 리뷰를 받은 사람은 어떻게 적용할지 고민이 필요하다. 적용을 안하게 된다면?

  → 일단 허용. 일단 시도해보자

게임 흐름도