3일차 회의록 (10월 30일)
-
성민) LiveEditorNet(LEN), connedit
-
현준)
octopus octo + … BoostNote
— SLOT: Structure Linked nOte Taking SLATE: Structured & Linked Adaptive Text Environment
-
서진
- ZettelFlow
- NoteForge
- NoteWeave
-
동준
- PageConnect
- Flow
-
예원
NodeBook → 있네- Nodion → node + notion
- NettedNote → 그물 모양의 노트
Octo + ???
- books
- collect
- node
- docs? → dog
- octoDocs
- map?
- zet 🚀
OctoZet 🚀
- 현준: 노트 관리 기법에서 따온 말이지만, 생산성 부스팅이라는 캐치프라이즈로 밀고 나갈 수 있을거 같다.
- 성민 : 어감이 착착 달라붙습니다.
- 동준: 더 특색이 있어 보인다고 생각했습니다.
- 서진: 일단 이게 더 입에 붙긴 하는데 제트라는 단어가 주는 상징적인 기능이나 디자인 따로 존재해야 할 것 같음
- 서비스의 목적이 바로 안와닿긴 함 (Octo vs. Zet =⇒ 둘 다 이미지로만 다가옴)
- GPT의 생각 : "Octozet"은 다리가 여덟 개 달린 로봇이나 생물체, 혹은 뭔가 SF적인 기술 장치의 이름처럼 들려요.
OctoDocs 🐶 vs 🐙 📝
- 예원 :
- Zet이라는 단어가 뭔지 모를거 같음
- 토젯 → ㅗ ㅔ 보다 토닥스 → ㅗ ㅏ 가 더 발음할 때 편함
- 로고를 일단 귀엽게 가능 (언어 유희 같은 느낌 (docs → dogs))
- 현준: 독스 하면 뭔가 닌텐독스 느낌나서 귀엽다 ← 저는 docs 한 표 (변절됨)
- 서진: 걍 입에 안붙는데…?
- ㅋㅋㅋㅋㅋㅋ
- GPT의 생각: "Octodocs"는 방대한 자료나 문서를 조직적으로 모아둔 문서 저장소나 문서 관리 시스템을 떠올리게 해요. 특히 여러 카테고리나 복잡한 자료를 다루는 문서 플랫폼이나, 다양한 주제나 기능에 관한 문서를 제공하는 도구로 활용될 수 있을 것 같습니다.
→ 저는 얘가 귀여움요
→ 귀엽 + 뭔지 바로 알 수 있는거 같아요 (직관적)
→ 이게 좋은 것 같아요
- 우선순위 가장 높은 핵심기능
- 노트 편집이 자유자제로 가능하다. (DB 연동 / 노드 CRUD - 연결 기능 제외) & 노트들을 노드 관계로 묶는다. (시각화 / 자유롭게 연결 & 해제)
- 실시간 동시 편집이 가능하다. (로그인 + 공유 링크…? excalidraw 처럼?)
- 우선순위가 비교적 낮은 응용기능
- 노드 응용 기능 (a + b / c + d)
-
노드 커스텀이 가능하다. (미리 보기로 어디까지 보여줄 것인지)
- 디폴트: 제목만 보이게
→ 세부 내용 (직접 쓰거나 / 문서 안에서 가져오거나 / 문서에 있는 이미지가 노드안에 보이게)
-
노드 → 비공개 / 공개 구분기능
- 접근 권한 / 편집 권한
- 노드와 연결된 다른 노드들은 자동으로 권한이 동일하게 설정
- 한 노드의 링크를 공유받은 사람은 해당 노드 + 자식노드들만 보임
-
-
- 우선순위가 가장 낮은 추가기능
- 노션 연동
- 파일 import
-
멘토링 일지
멘토링 이후 결론과 챙길 것을 정리하여 업데이트합니다.
멘토링 24시간 전에 준비하여 멘토에게 공유합니다.
멘토의 조언이 필요한 부분을 질문으로 정리합니다.
멘토가 일지를 보고 멘토링을 준비할 수 있도록, 팀의 진행상황과 참고 자료를 정리해서 넣어주세요.
멘토링을 진행하며 나눈 이야기가 휘발되지 않게 기록해보세요.
1주차 멘토링에서 이야기 나누면 좋을 주제입니다. 우리 팀의 상황은 어떤가요? 팀원 및 멘토와 함께 셀프 체크하고, 그 이유를 작성해보세요. 추가하고 싶은 항목이 있다면 직접 추가해도 좋습니다.
- 프로젝트 기획과 설계의 뼈대가 나왔다.
- 프로덕트 backlog가 제작되었다.
- 서비스 핵심 기능에 대한 완성도의 기준 또는 기술적 목표가 수립되었다.
- 현실성 있는 계획이 수립되었다.
-
저장소
[**boostcampwm-2024](https://github.com/boostcampwm-2024) 기관 아래에 팀별 저장소를 생성한다 ◦ 팀내 분야별로 저장소를 나누지는 않고, 반드시 하나의 저장소에서 관리한다저장소는 단순히 코드만 올리는 곳이 아니라 프로젝트 활동의 모든 자료에 접근할 수 있어야 한다README에는 다음과 같은 내용을 포함한다 ◦ 팀원 소개 ◦ 협업 전략 (브랜치 구조와 분업하기, 의존적인 작업하기) ◦ 그라운드룰 (최소한의 규칙, 무엇이 필요한가는 다같이 찾아보세요) ◦ 기획/디자인 링크 ◦
커밋 템플릿, 이슈 템플릿: 개발 작업을 위한 공통 자료 ◦회의록/이슈/위키 연결: 협업과 개발 과정의 문서 자료 ◦ 배포 링크가 있을 경우 해당 링크도 기술깃헙에 default 브랜치를 지정하고, 개발용 브랜치를 내부적으로 지정한다feature 개발이 끝나면 바로바로 개발용 dev 브랜치로 머지한다 ◦ 하루 최소 1회 이상 머지한다**-
[boostcampwm-2024](https://github.com/boostcampwm-2024) 기관 아래에 팀별 저장소를 생성한다
-
◦
팀내 분야별로 저장소를 나누지는 않고, 반드시 하나의 저장소에서 관리한다
-
-
팀내 분야별로 저장소를 나누지는 않고, 반드시 하나의 저장소에서 관리한다
-
저장소는 단순히 코드만 올리는 곳이 아니라 프로젝트 활동의 모든 자료에 접근할 수 있어야 한다
-
README에는 다음과 같은 내용을 포함한다
-
◦
팀원 소개
-
◦
협업 전략 (브랜치 구조와 분업하기, 의존적인 작업하기)
-
◦
그라운드룰 (최소한의 규칙, 무엇이 필요한가는 다같이 찾아보세요)
-
◦
기획/디자인 링크
-
◦
커밋 템플릿, 이슈 템플릿: 개발 작업을 위한 공통 자료 -
◦
회의록/이슈/위키 연결: 협업과 개발 과정의 문서 자료 -
◦
배포 링크가 있을 경우 해당 링크도 기술
-
-
팀원 소개
-
협업 전략 (브랜치 구조와 분업하기, 의존적인 작업하기)
-
그라운드룰 (최소한의 규칙, 무엇이 필요한가는 다같이 찾아보세요)
-
기획/디자인 링크
-
커밋 템플릿, 이슈 템플릿: 개발 작업을 위한 공통 자료 -
회의록/이슈/위키 연결: 협업과 개발 과정의 문서 자료 -
배포 링크가 있을 경우 해당 링크도 기술
-
깃헙에 default 브랜치를 지정하고, 개발용 브랜치를 내부적으로 지정한다
-
feature 개발이 끝나면 바로바로 개발용 dev 브랜치로 머지한다
-
◦
하루 최소 1회 이상 머지한다
-
-
하루 최소 1회 이상 머지한다
-
-
1주차 활동 가이드
-
프로젝트 설계
- 기획서 작성
- 비즈니스나 마케팅 관점보다는 팀의 기술적 역량을 갈고 닦을 수 있는 서비스를 고민해보세요.
- 선택한 주제의 핵심 키워드 내에서 하위 기능 변경 및 기획서 업데이트가 가능합니다.
- 디자인적인 미려함을 지나치게 고려하지 않아도 괜찮습니다.
- 앱은 앱 스토어에 올라간다는 가정하에 필요한 내용을 준비합니다.
- 개발에 이견이 없도록 요구사항 정의를 충실히 하세요. ****필수 동작 사항에 대한 설명을 포함해야 합니다.
- 서비스가 실제 운영이 되었을 때 마주할 수 있는 문제 상황을 가정해봐도 좋습니다.
- 기획서 작성 도구는 자유지만 공동 편집이 가능해야 합니다.
- 비즈니스나 마케팅 관점보다는 팀의 기술적 역량을 갈고 닦을 수 있는 서비스를 고민해보세요.
- Feature List 및 프로덕트 backlog 작성
-
요구사항(Spec)을 기반으로 기능을(Feature)을 정의하고 그것을 할 일(Task)로 세분화 해보세요.
-
전체 기능 목록은 [프로덕트 backlog] 형태로 GitHub에 표현되어야 합니다.
-
백로그는 GitHub의 issue, project 혹은 구글 스프레드시트 중 원하는 것을 선택하여 사용합니다.
-
backlog 작성 예시
-
-
프로젝트 저장소 wiki에 통합 정리합니다.- 외부 플랫폼 사용 시 누구나 접근 가능한 URL를 기재합니다.
-
- 기획서 작성
-
기획 공유 (Day5)
- 1주차 금요일(11/1) [프로젝트 현황 공유] 시간에는 기획, 설계 내용을 동료에게 공유합니다.
- 팀 당 20분간 발표(15분)와 질의응답(5분)시간을 갖습니다.
- 서비스의 주요 목표 및 핵심 기능과 선정 이유를 Feature List 및 프로덕트 backlog를 중심으로 발표합니다.
- 기능 별 완성도 기준이 있다면 포함하여 소개합니다.
- 팀 빌딩 및 그라운드 룰에 대해 소개해도 좋습니다.
-
더욱 의미있는 공유를 위해 적극적인
피드백이 필요합니다.- 팀 별 피드백을 작성할 수 있는 피드백 노트가 제공됩니다.
- 발표에 대한 소감과 질문 및 피드백을 아낌없이 남겨주세요.
- 더 좋은 프로젝트가 될 수 있도록 새로운 관점에서 의견을 제시합니다.
-
- React Flow 기본 제공 기능
- React Flow 기본 제공 기능
- default는 일단 미리보기 칸은 최대한 작게, 제목만 보이게
- 미리보기에 내용이 늘어날 수록 노드의 크기는 커진다
⇒ 나중에 정해야 할것들이 많다
(권한 관련된 사항은 고민할 게 많아보입니다)
- 주목적이 공유 (figma) → 기본적으로 편집, 보기 권한이 열려있음?
- 주목적이 문서 관리 (notion) → 기본적으로 비공개
- 태그랑 메타데이터를 AI 가 관리해준다
- GPT마냥 내용 생성 / 첨삭
- …
- 노트 생성 시 노드를 자동으로 추가하는게 좋은가? → O
- 노드의 사이즈를 사용자가 조절할 수 있는가? → 일단은 X
- 로그인?? → 일단은 X
- 멘토링 준비 (목)
- 일정 정하기
- 질문 할것 정해보기
- (스크럼 전까지!) 태스크 써보기 (에픽 1: 페이지 편집, 에픽2 : 노드 관계)
- 소켓과 3번째 에픽의 태스크 관련하여 생각해보기
- 발표 준비 (목)