Analysis Engine - 1. Technical Consensus

[ansrlm]

!

목표 및 참고사항은 "강제"가 아니며 "정답"이 아닙니다. 자유롭게 댓글 작성 부탁드립니다 :)
추가 필요한 feature와 좋은 의견 많은 관심 부탁드립니다~

목표

• analysis engine의 feature리스트를 어느정도 완성합니다.
  • 현재 등록되어 있는 https://github.com/orgs/githru/projects/2 에 더해서 필요하다고 생각되는 피쳐들을 추가합니다.
  • (italic은 과제에서 어느정도 해결된 feature입니다)
    • crawler: git log 연동
    • crawler: git ref (for PR)
    • crawler: git log + PR info
    • analysis engine: build DAG
    • analysis engine: build main tree based on the main branch - first parent (recursively)
    • analysis engine: cluster info
    • analysis engine: remained implicits, PRs
    • crawler: user info from Github
    • ...
  • 해당 discussion에서 다루지 않습니다.
    • feature의 포함 범위
    • 기술적 한계
    • 상세한 방향성
    • 등록된 feature에 대한 분리 여부
    • ...
• 유지보수를 잘 하기 위해 공통으로 적용할 항목들에 대해 협의합니다.
  • eslint rule sets
  • test 전략 (테스트 범위, coverage, ...)
  • coding conventions
    • directory structure
    • file naming
  • bundler
  • ...

참고사항

• feature에 대한 진행 방법은 해당 discussion에서 다루거나 추가 discussion에서 다룹니다.
  • feature간 생길 수 있는 종속성에 따라 선행성 부여
    • 종속성이 부여된 경우 완료일에 대한 산정이 필요할까요?
  • 각 feature에 대한 담당자 지원 방식
    • 개인
    • volumn이 큰 feature에 대해서
      • 페어 프로그래밍
      • 기능별 feature 분리
    • 자유
• feature에 대한 대략적 아이디에이션이 완료되면 멘토님께 회의를 요청할 예정입니다.
  • feature에 대한 micro한 영역의 내용 확인
  • 방향성 확인

[ansrlm]

추가항목

• 테스트 프레임워크 선정
  • jest
  • mocha
• prettier config 선택
  • 우리들만의 rule을 선택
  • company (airbnb / uber ...)
• 가이드 페이지가 필요할까요?

피쳐 우선순위

Main

1. git log schema 정의
2. crawler: git log 연동 : Main1 함께 수행 가능
3. git ref schema 및 PR에서 필요한 정보 추출. git ref : feature 구체화 필요. 독립적 수행 가능
4. analysis engine: build DAG : Main2 완료 이후 수행 가능
5. analysis engine: build main tree based on the main branch - first parent (recursively) : Main4 완료 이후 수행 가능

Side A

1. user info schema 정의
2. crawler: user info from Github
3. PR info schema 정의
4. crawler: PR info

Side B

1. analysis engine: cluster info : Main1 완료 이후 수행 가능하나 Main1의 경우 미리 해결이 가능한 것으로 보임
2. cluster - engine 연동 : Main2, Side B2 완료 이후 수행 가능
3. analysis engine: remained implicits, PRs

DevOps

1. 파이프라인 구성 (bundler / test / eslint / prettier)
2. readme 페이지 구성

[hy57in]

• 리뷰어는 최소 2명! 대신 서로 활발하게 리뷰 해주기
• 목표가 빠른 배포이지만, TDD를 경험해보는 것도 좋을 것 같다. CI, test는 강제하는거 어떤가 (멘토님 의견ㅋㅋ)
• 일단 coverage 수치는 고려하지 않는걸로 (빠른 개발 생산성을 위해)

[hy57in]

문기님 : esbuild 사용. node_module을 사용하기 부적합할것 같기도? 버전도 불안정하고. rollup이 더 낫지 않을까?
멘토님 : react는 webpack 사용. 통일할 필요는 없을까? -> engine은 rollup 써볼깡

결론 : engine은 rollup 써보고.. 한번 살펴보자! 도전! 문제 생기면 webpack으로 마이그레이션..

[hy57in]

devOps 담당 : 문기님 🎉

[anpaul0615]

위 논의상항들과 함께 마스터즈 기간 내 엔진팀 목표를 정리하는 것도 같이 생각해보면 좋겠습니다.

아래는 약 4주 기간을 기준으로 한 목표에 대한 개인적인 의견입니다.

• 기본 달성목표 (=프로그램으로 구현해야할 최소 기능)

  • input : git log 출력, github PR/Issue
  • output :
    • commits.json
    • pulls.json
    • issues.json
    • score.json
    • corpus.json
    • nlp.json

• view ↔ engine 간 통신을 통한 데이터처리는 제외 (ex. 클러스터링 동적 처리)

• 조금 더 확실한 배포플랜을 위해서 아예 클러스터링 자체를 제외하는것도 생각해볼만함
  ex) v0.1 에서는 STEM + CSM 만 보여주기

[hy57in]

조금 더 확실한 배포플랜

우리의 목표는 배포!
MVP를 작게 만들어 우선 마켓플레이스에 배포하는 것을 목표로 하면 어떨까.

-> feature를 쳐내는 논의가 필요하다.

[hy57in]

git log 출력 기반으로
1차 : CSM-base-commit 단위로 나타내기
2차 : 클러스터링

github PR/Issue는 어떻게 나타내는거였는지 기억안남

[anpaul0615]

회의 협의 내용

• v0.1: PR제외 STEM + CSM
• v0.2: Github PR지원
• v0.3: ...

[ansrlm]

회의 피쳐 리스트 재산정 (v.0.1)

• git log
• DAG
• STEM
• CSM

[anpaul0615]

독립적으로 진행할수있는 feature

• crawler: user info from Github

[ansrlm]

기술적 선택

• airbnb (eslint / prettier)
• coverage
  • 0
• bundler
  • rollup

[ansrlm]

추가 discussion (생성 예정)

• feature에 대해 생각하는 방향 각자 정리 및 공유
  • git log
  • DAG
  • STEM
  • CSM
  • User info
• 자신에게 잘 맞는 coding convention예시 공유

[blcklamb]

CSM이 어떤 것의 약자인지 알 수 있을까요?

[ansrlm]

Context-Preserving Squash Merge의 약자 입니다.
한번 쭉 보시는 것도 좋을 것 같아서
프로젝트 참가 신청서에 있었던 논문 링크 다시 공유드려요. https://ieeexplore.ieee.org/document/9222261

+저도 채정님이 리마인드 주셔서 다시 한번 봐야할 것 같네요 ㅎㅎ 기회가 있다면 같이 이야기 나누어 보아도 좋을 것 같습니다.