프로젝트 방향

1. 평소에 구현하고 싶었던 기능 구현
2. 많은 인원들과 협업하며 대규모 프로젝트에 대한 경험 쌓기

프로젝트 규칙

1. 매주 1회 이상의 정기적인 회의를 통해 팀 내의 진행상황을 공유해야 한다.
   1. 정기 회의는 간단한 회의록을 작성하여, 결과물을 팀장 미팅에서 공유하도록 한다.
   2. 정기 회의는 기본적으로 비대면이나, 팀 내부적으로 조율 후에 대면으로 진행하는 것을 허용한다.
2. 각 팀의 팀장은 매주 1회 이상의 정기적인 회의를 통해 팀 내의 진행상황을 공유해야한다.
   1. 각 팀간의 애로사항 및 진척도를 공유한다.
3. 대화는 디스코드를 통해서 진행하며, 모두 부르는 호칭은 ~님이며, 서로 존댓말로 이야기한다. 또한 디스코드 닉네임은 실명으로 한다.
4. 모든 의사결정에는 이유가 있어야 하며, 의사결정까지의 과정을 회의기록에 남긴다.
5. 원하는 기능이 있다면, 디스코드를 통해 혹은 오프라인에서 원하는 기능에 대한 팀을 결성하여 기능을 구현한다.
6. 애자일 방법론의 “스크럼”을 활용하여, 1개의 스프린트를 매주 일요일을 스프린트의 기준으로 삼고, 1주일마다 스프린트로 지정해서 기능 개발한다. 규칙 1번에 나와있듯이, 스프린트 1개 안에 1회 이상의 회의가 있어야한다.

Conventions

1. Github의 Organization을 활용하여, repository를 관리한다.

   1. 레포지토리는 웹은 1개의 레포, 서버는 코틀린/파이썬으로 구분된 모노레포로 작성한다.

2. 필요한 기능, 수정해야하는 기능들에 대해서는 Github의 issue기능을 활용하여 작업을 한다.

   Issue

3. 코드리뷰를 통해 코드의 품질을 높이고, 지속적으로 성장할 수 있도록 돕는다.

   Discord의 웹훅 기능을 활용하여 팀별 대화방에 repository에 커밋 혹은 리뷰가 달린 것에 대해서 확인한다.

4. Github Action을 통해 CI/CD를 하고, 자동화된 배포 시스템을 통해 배포한다.

5. Github-Flow를 통해 빠른 시스템 구현에 초점을 맞춘다.

6. 모든 브랜치의 중심은 main으로 하며, 이후

Issue