회의록 - Born-in-Idiots/ARTIFY GitHub Wiki

2/2 미팅내용

2/2 미팅내용

  • 프로젝트 일정관련

    • 각 파트 기능정의 디테일 (1주)
    • Git Action 적용 (2주)
      • Choice 01 : Wiki에 세부적으로 정리된 파트별 기능을 보고 개인 repo에서 branch 따서 project repo의 dev branch에 pr날린다.
      • Choice 02 : Git Action으로 자동화 해서 개인 repo에서 branch 따서 project repo의 dev branch에 pr날린다. ✅
    • 조정된 프로젝트 Sprint
      • Sprint 01 : ~2/2 (일)
      • Sprint 02 : ~2/9 (일)
      • Sprint 03 : ~2/16 (일)
      • Sprint 04 : ~2/23 (일)
      • Sprint 05 : ~3/2 (일)
      • Sprint 06 : ~3/16 (일)
      • Sprint 07 : ~3/23 (일)
      • Sprint 08 : ~3/30 (일)
      • Sprint 09 : ~4/6 (일)
      • Sprint 10 : ~4/13 (일)
      • Sprint 11 : ~4/20 (일)

  • 개발문서 관련

    • Github Wiki
    • 공통 회의록
    • 프로젝트 공통내역 정리
    • 각 part별 기능정의 (api 문서)
      • Step 01. 파트별 api 문서 정리가 우선완료
      • Step 02. api문서를 바탕으로 실 개발과정에서 발생하는 다양한 상황들을 issue로 발행

  • 개발레포 관련

    • 2/4(화) 저녁 9시 미팅 : 형순, 재훈

  • 개발소통도구 관련

    • Discord

  • 디자인

    • 병근이가 보고 서비스 기능관점에서 변경/수정될 사항 임의대로 반영하기 (사전 정의된 기능만 모두 포함되면 디자인, UI/UX 변경여부 관계없음 = 니 맘대로 하셈)

  • Sprint별 기능정의 (~ Sprint 03)

    • : Sprint별 기능정의
    • : Sprint별 기능정의
    • : Sprint별 기능정의 , API 문서정의

  • 회의 날짜 변경

    • 2/9 (일) -> 2/10 (월) 밤 8시 30분
    • 2/16(일) -> 2/14 (금) 밤 8시 30분
2/4 미팅내용

2/4 미팅내용

  1. Label

  • 📘 API => 서버 API 관련

  • 🐞 Bugfix => Something isn't working

  • 🌏 Deploy => 배포 관련

  • 📃 Docs => 문서 작성 및 수정 ( README.md 등 )

  • 💻 Feature => 기능 개발

  • 😭 Help => 도움 필요

  • 🙋‍♂️ Question => Further information is requested

  • 🔨 Refactoring => 코드 리팩토링

  • ⚙ Setting => 개발 환경 세팅

  • ✅ Test => Test 관련

  • 작업 영역으로도 나누기도 함

    • FE
    • BE
    • BE : Proxy

  • 작업 유형으로 나눔 : 위의 예시

  • 우선 순위로 나눔 ( 긴급성 구분 )

    • priority : high, medium, low

  • 진행 상태로 나눔

    • Status : in progress, review, etc...

고민 필요

  • 작업 영역 관련 Label이 필요할까? => 왜 필요할까?

  • 작업 영역으로 label을 나누면 각 파트?별로 구분하기 쉬움

  • 추후에 작업 영역으로 필터링해서 자기가 작업한 issue, pr을 볼 수있음

  • 디자인(UI) 관련 Label이 필요할까? => 기능으로 보긴 어렵고, 코드 리팩토링이랑 관련이 없음

    • 디자인 관련 작업만 있을 수 있음
    • FE에서 버그가 발생했는데 기능에서 버그인지 디자인(UI)에서 버그인지 구분가능하지 않을까?

  • 진행 상태로도 나누는게 맞나??

    • Bug 랑 BugFix 두가지로 나눠야할듯?
    • Bug => Issue 발행할 때 사용하고
    • BugFix => PR 생성할 때 사용

  • 기능 개발 label을 상세화 해야되는가?

  • 다른 누군가가 다른 파트의 기능 개발 요청을 할 수 있음

  • 자기 파트의 기능 개발 label을 쓸 수 있음=> 차이가 있음

    • 의견) 기능 개발 Label 하나 고정으로 하고 "요청 사항" 이라는 label을 넣는게 더 나을려나?

  • 결론

  1. 작업 영역에 대한 것은 prefix로 붙이는게 유용해 보임! (형식은 우리가 정하면 되는부분!)
  • ex) [FE] main view 개발
  1. Prefix 종류
  • [FE] : Frontend
  • [BE] : Backend
  • [BE-P] : Backend Proxy
  1. Description 규칙
  • 동사 명사 순으로 작성
  • 첫단어 동사 는 해당 issue의 목적이 드러나는 행동의 의미를 담아야 함.
  • 두번째 단어 명사 는 첫단어의 대상이 위치해야 함.
  • 이외 다른 설명은 자유롭게 작성해도 무방함.
  • 전체 description은 3~4글자 영문으로 작성 (대소문자 상관 x)
    • 예시)
      • 로그인 API 수정 : Edit Login API
      • 로그아웃 기능추가 : Add Logout Feature
  1. Issue 발행 네이밍
  • {Prefix} : {description}
    • ex) [BE] : edit login api
  1. PR 발행 네이밍
  • {Prefix}
  1. 디자인 관련 label 추가 x, 토의는 기록이 남는방향으로!
  1. 진행 상태는 Label에 추가하여 사용 (작업 전, 작업 중, 작업 완료), Issue 안에서 작업상태를 관리
  1. Label 최종
  • 📘 API : API 통신 관련
  • 🐞 BugFix : 버그 수정 (pr)
  • 🅱️ Bug : 버그 발생 (issue)
  • 🌏 Deploy : 배포 관련
  • 📃 Docs : 문서 작성 및 수정 ( README.md 등 )
  • 💻 Feature : 기능 개발
  • 🔨 Refactoring : 코드 리팩토링
  • 🥑 Environment : 환경 세팅
  • 📝 Test : Test 관련
  • 🤝 Request : 요청사항
  • ⬜ Task : 작업 전
  • ▶️ In Progress : 작업 중
  • ✅ Done : 작업 완료
2/10 미팅내용

2/10 미팅내용

  1. 결정사항 전달 : ✅

  2. Code Review 주기 : 1주 1회 진행 (해보고 수정)

  3. PR 상태를 고려하여 review 진행여부 결정

  4. Convention

  • Issue : (Y)

  • Length : 6~7 word

  • Naming : {Prefix} : {description}

  • PR : (Y)

  • Naming : {Prefix} : {description}

  • Commit : (Y)

  • Length : 3~4 word

  • Naming : {Prefix} : {description}

  • Note : 너무 자잘한 commit은 지양하자, External description 필수, 작성시 제약 x : git commit -m '__msg__' -m '__external_msg__'

  • Code Convention :

    • 함수 명 : 직관적으로 해석이 되는 명칭
    • 변수 명 : 직관적으로 해석이 되는 명칭
    • 각주 : 최소단위는 하나의 모듈화 된 함수 (하나의 기능은 최소단위가 함수 혹은 함수가 모인 클래스)

  • PR 네이밍

    • PR Tag
      • 처음부터 새로 만들어내면 : create
      • 이미 존재하는 것에 추가하는 것이면 : add
      • 어떤 것의 속성을 바꾼다면 : modify
      • 데이터를 바꾼다면 : update
      • 기존의 것을 완전히 대체한다면 : change
      • 영구적인 삭제는 : delete

  • Naming : {prefix} : {PR Tag} {description}

@misc{ARTIFY,
    author = {Born-to-be-Idiots},
    title = {ARTIFY : ART OF THE SYNTHESIS PLATFORM OF AI},
    year = {2025},
    publisher = {@ash-hun, @Dejong1706, @HS980924},
    journal = {GitHub repository},
    howpublished = {\url{https://github.com/Born-in-Idiots/ARTIFY}},
    }
⚠️ **GitHub.com Fallback** ⚠️