구성하여 하나의 오픈소스를 집중적으로 배우고 개발(intensive learning and development) 합니다. 기여자들에게는 얼굴을 맞대고(face-to-face) 오픈소스에 다가갈 수 있는 기회입니다. 행사를 넘어서서 우정을 만드는(relationship) 시간입니다. ◦ SprintSeoul 오픈소스 프로젝트의 작성자/기여자와 함께 짧은 시간 동안 문제를 찾고 해결합니다. 자세한 설명을 직접 듣고 혼자서 하는 것보다 쉽게 문제를 해결할 수 있는 기회입니다. 오픈소스 프로젝트 작성자는 스프린트를 통해 새로운 기여자를 발견할 수 있습니다. 준비 과정 1 - 검색&정리&검색&설득
lines라구요…? ◦ 요약 ▪ Why, Who, What, Where, When을 생각하자 ▪ 오픈소스 기여 이벤트의 세 가지 핵심 • ① 접근성 - 사람들이 쉽게 올 수 있어야한다. • ② 안전과 보안 - 참가자들이 안심하고 집중할 수 있어야 한다.(랩탑의 분실을 방지) • ③ 협업, 행동, 예절에 대한 가이드라인 - 명확한 기여 가이드라인과 코딩의 표준이 마련되어야 한다. ▪ 행사 2달 / 6주 / 2주 / 1주 / 하루 전에는 ~를 준비하세요. 준비 과정 1 - 검색&정리&검색&설득
있도록 라인 직원을 대상으로 한다. ▪ 회사에서(혹은 회사 근처에서) 평일 어느 날 • ①접근성, ②안전과 보안 ◦ [When] 하루에 몰아서 하는 것은 오히려 집중력에 방해가 될 것 같다. ▪ 오리엔테이션과 코딩 세션을 다른 날짜로 분리하기 ◦ [Why] 아직 경험치가 부족하기 때문에! 따라서 성과보다는 경험에 더 집중한다. ▪ (참가자의 경험) 오픈소스에 대한 막연한 두려움을 깨고 지속적으로 활동을 이어나갈 수 있도록 ▪ (진행자의 경험) 앞으로도 새롭고 완성도 있는 행사를 진행할 수 있는 자신감 가지기 준비 과정 1 - 검색&정리&검색&설득
회사 회의실 : 넓고 쾌적한데, 업무 공간과 붙어있어서 방해 요소가 많음(회의 등) ◦ 스터디룸 : 15명의 사람과 랩탑이 모일만한 장소가 마땅치 않음 ◦ 안정적인 네트워크! • 오리엔테이션 준비 ◦ 진행 방식 정하기 ◦ CONTRIBUTING.md 설명 ▪ ICLA(Individual Contributor License Agreement) ▪ Code of Conduct ◦ 회사의 오픈소스에 대한 방침에 대해서(업무와 무관/유관한 오픈소스 활동을 하는 경우)
동의서 ◦ 세 줄 요약 ▪ 코드를 기여하게 되면 오픈소스와 동일한 조건으로 공개가 되는 것을 동의하는가? ▪ 기여자/프로젝트/유저를 모두 보호하기 위한 목적 ▪ 오픈소스는 기여자에게 책임이나 지원을 요구하지 않을 것이고, 기여자는 사용자들에게 저작권/특허권 이용을 허락할 것을 약속 준비 과정 3 - 본격 준비
또는 회고 질문 ▪ 만족도(점수) ▪ 행사 전에 기대했던 것과 같은지? 다르다면 어떤 점에서? ▪ 불편한/어려웠던 점이 있었다면 어떤 점인지? ▪ 좋았던 점이 있었다면 어떤 점이 좋았는지? ▪ 아무 말이나 소감 ▪ 멘토들의 소감 ▪ 앞으로의 계획 준비 과정 4 - 마무리 준비
❏ 진행자(&멘토)와 공감하기 ❏ 언제, 어디서, 누구와, 무엇을, 어떻게, 왜? 에 대하여 ❏ 홍보 ❏ 참가 신청 페이지 or 메일 ❏ 커뮤니케이션 채널 운영 ❏ 정리할 것 ❏ 진행 방식 - 어떤 행동과 어떤 결과를 유도할지 ❏ CONTRIBUTING.md 상세 설명 ❏ 설문/회고, 블로그(혹은 소셜) ❏ 필요한 것 ❏ 장소, 음료&간식, 프로젝터(오리엔테이션 용), 스피커, 멀티탭, 필기구(화이트보드) 등 FAQ - 오픈소스에 기여할 정도까지는 실력이 안되는 것 같은데 참가해봐도 괜찮을까요? (자신감 부족) - 정해진 시간 안에 못마치면 어떡하죠? - Armeria에 익숙하지 않은데 괜찮은가요? 이 내용들을 포함하도록! 코딩시간이 너-무 고요해서…(white noise)
11, Gradle, … ◦ 개발 환경 설정 방법 ◦ 코딩 스타일 가이드 ◦ Code of Conduct ◦ CLA (Contributor License Agreement) • 처음부터 따라 해 보자 ◦ 예전과는 뭔가 달라졌을 지도? • 많은 ‘good-first-issue’를 준비해 두자 ◦ 선택의 폭 ◦ 다음 번 스프린트 대비 • 멘티가 준비할 것을 잘 공지해 당일 시간 낭비를 줄이자
◦ 해당 또는 유사 프로젝트 사용 경험이 조금은 있어야 • CONTRIBUTING.md를 읽어 두자 ◦ (선택) 미리 환경을 셋업해 두면 좋다 • 리파지터리를 클론해 두자 ◦ 클로닝이 오래 걸리거나 현장 상황에 의해 실패할 수 있다 • 빌드를 한 번 정도 돌려 두자 ◦ 디펜던시 다운로드가 오래 걸릴 수 있다 ◦ 예기치 않은 환경 문제가 있을 수 있다 ▪ 해결이 안 되면 운영진에 미리 문의해 보자 • (선택) 이슈 트래커에서 ‘good-first-issue’를 둘러보자
지식이 부족해도 해결할 수 있어야 • 다양한 난이도의 이슈를 준비하자 ◦ 멘티마다 여유가 다르니까 • 적당히 작게 쪼개자 ◦ 이렇게 쪼개도 다들 토끼굴에 빠지게 된다! • 지루하거나 피상적인 이슈는 피하자 ◦ One-liners ◦ 문서화 (프로젝트 특성이나 스프린트 테마에 따라) ◦ 디펜던시 업데이트
소개 ◦ 스프린트에 어떻게 오게 되었는지 ◦ 얻고자 하는 것이 무엇인지 • CONTRIBUTING.md 함께 읽고 따라 하기 ◦ 화면을 보고 따라 할 수 있게 • Good first issues 소개 및 할당 ◦ 멘터 - 설명 · 동기부여 ◦ 멘티 - 맘에 드는 이슈 선점(!)
• 일반적인 코드 리뷰 과정 • 포기하지 않도록 이끌자 ◦ Gentle pings ◦ 어떤 부분이 어려운지? • 머지가 되었다면 축하하자 ◦ “... 그런데 자네 이 이슈도 한 번 해 보면 어떻겠나?” • 때로는 포기자도 생기지만… ◦ 너무 슬퍼는 말자ㅠ "좋은 경험이었어..."
7개의 머지된 pull request ◦ 1명의 멘티로부터 1개의 진행 중인 pull request ◦ 4명...ㅠ • 모든 멘티가 미완성 pull request를 행사일에 올리도록 했다면 ◦ 당일에 올리지 못한 경우 성공 확률이 낮다 ◦ 부족한 부분이 있더라도 draft PR을 올리도록 격려해 논의가 이어질 수 있도록 하자
당황할 수도 있다 • 행사 후에도 정기적인 follow-up 모임을 가졌다면 ◦ 멘티들에게 따로 시간을 낼 계기를 주자 • 선택한 이슈마다 난이도에 따라 소요 시간이 다를 수 있다는 점을 미리 공지했다면 ◦ 멘티들의 불안감을 잠재울 수 있는 방법을 생각하자 • 오픈 소스가 아닌 사내 프로젝트에 스프린트를 적용해 보면!?