Hacktoberfest는 DigitalOcean에서 주관하는 행사로 예전에는 GitHub하고 함께 했는데 올해는 Intel과 Dev.to와 같이 주최했다. Hacktoberfest는 Hacking과 Octoberfest를 합쳐서 만든 이름으로 매년 10월에 4개의 Pull Request를 GitHub에서 올리면 티셔츠를 주는 행사이다. 올해는 티셔츠 대신 나무를 심는 옵션을 선택할 수 있다.

올해가 7번째로 알고 있는데 나는 두 번째인 2015년부터 참가했다. 내 기억으로는 2016년도 참가했는데 배송사고인지 티셔츠를 받지 못해서 위 사진처럼 4장의 티셔츠만 가지고 있다.

Hacktoberfest는 말 그대로 Pull Request를 4개만 올리면 되고 따로 꼭 머지가 되어야 하거나 하는 조건은 없었다. 대신 메인테이너가 invalid 라벨을 달면 카운트가 되지 않는다. 평소에도 오픈소스에 기여를 틈틈이 하고 있기 때문에 10월에만 좀 더 신경 써서 열심히 Pull Request를 올리면 어렵지 않게 4개의 PR 조건을 달성할 수 있었다. 올려진 PR이 유효한지 의미 있는지를 자동화하기는 쉽지 않기 때문에 조건은 엄격하게 가져가지 않고 많은 사람이 참여할 수 있게 한 것으로 보인다.

그래서 이전에도 보면 실제 프로젝트가 아니라 Hacktoberfest 용으로 만들어진 저장소에 올려진 Pull Request가 상당히 많았다. 어떤 면에서는 실제 프로젝트가 아니기에 오픈소스에 직접적으로 도움이 되진 않지만, 또 처음 GitHub에 PR을 올려보는 등의 경험을 해보게 하는 면에서는 전혀 의미가 없다고 할 수는 없다. 나한테 Hacktoberfest는 그런 취지의 행사였다. 실제로 PR 4개가 실제로 의미 있는 PR로만 올리려면 한 달 내내 계속 신경 쓰지 않으면 아주 쉬운 조건은 아니다.

Hacktoberfest 스팸 문제

여기서 스팸이라고 부르는 것은 의미 없는 Pull Request가 올라오는 것을 말하는데 예전에도 이런 문제는 있었다. 10월에 유독 사소한 문서 수정이나 의미 없는 PR이 종종 올라오고 메인테이너들은 대부분 Hacktoberfest 때문이란 것을 알고 있었다.

작년까지와 다르게 올해 Hacktoberfest는 시작부터 시끄러웠다.

PLEASE don’t do this. @hacktoberfest, you are encouraging spam and creating noise. pic.twitter.com/x8VPxunPTh

— Dan Abramov (@dan_abramov) October 1, 2020

React 같은 유명 프로젝트에 amazing super project 같은 불필요한 문구를 추가하는 PR 때문에 Dan Abramov처럼 유명한 개발자가 이를 비판하면서 수많은 개발자가 Hacktoberfest의 문제점을 지적하기 시작했고 꽤 많은 프로젝트가 의미 없는 PR을 닫느라고 메인테이너들의 시간을 낭비하기 시작했다. 듣기로는 꽤 유명한 유튜버가 이런 식으로 PR을 올리면 쉽게 티셔츠를 얻을 수 있다고 안내했다고 한다. 그래서 이런 PR만 모아놓은 shitoberfest라는 트위터 계정까지 생겼다.

디지털오션에서 발 빠르게 대처해서 Hacktoberfest를 옵트인 방식으로 기준을 변경했다. 10월 3일에 공지했으니 꽤 빠른 조치였다. 이전에는 GitHub의 모든 저장소에서 다 참가할 수 있었지만 이벤 저장소의 메인테이너가 토픽에 hacktoberfest라고 지정한 프로젝트나 토픽이 없더라도 hacktoberfest-accepted라는 라벨을 달아야만 인정되는 방식으로 바뀌었다. 그래서 Hacktoberfest에 참여하는 프로젝트와 아닌 프로젝트가 나뉘게 되었다. 물론 참가자들이 규칙을 다 이해 못했는지 여전히 참여 안 한 프로젝트에도 스팸 PR이 종종 올라오긴 한 것 같다.

Hacktoberfest 참가

매년 하던 행사라 당연히 참여하려고 생각하다가 시작부터 시끄러우니 생각이 좀 많아졌다. 참가자가 많아지면 당연히 잡음이 커지기 마련이지만 이번에는 행사의 의도가 왜곡될 정도로 문제가 생긴 것 같아서 Hacktoberfest에 참여하는 게 맞나 하는 생각을 했다. Hacktoberfest Seoul에서도 발표하기로 했기 때문에 고민은 더 많았다.

디지털오션의 대처도 빨라서 수습되는 분위기기도 했고 오픈소스 생태계에 도움 안 되는 마이너스 행위가 너무 많았으니 원래 행사 취지에 맞게 플러스 행위를 더 늘리자는 생각으로 참여하기로 했다. 이전에는 평소에 내가 참여하던 프로젝트에 PR을 더 열심히 올리면 해결되었지만 이번에는 내가 참여하는 프로젝트가 Hacktoberfest에 참여하고 있지 않았기 때문에 다른 프로젝트를 찾아야 했다. Hacktoberfest의 목적에 맞게 그동안 참여 안 하던 오픈소스에 4개의 PR을 올리는 것을 목표로 잡았다.

GitHub에서 토픽으로 저장소를 찾을 수 있음으로 여기서 언어 등으로 검색해 보면서 내가 참여해 볼 만한 프로젝트를 찾아봤다. 기여 안 하던 프로젝트에 갑자기 기여하는건 쉽지 않음으로 프로젝트마다 good first issue나 hacktoberfest같은 라벨이 있는 이슈 위주로 보면서 해결할만한 게 있나 찾아봤다.

1. badges/shields의 문서 링크 수정

저장소를 찾아보다가 Shields.io를 발견했다. Shields는 README 문서에 프로젝트의 상태 등을 표시하는 배지를 모아놓은 저장소이다. 요즘은 배지가 많아서 Shields를 적극적으로 쓰고 있진 않지만 배지 종류가 많아서 알고 있던 프로젝트다.

코드를 보는 건 처음인데 TUTORIAL.md를 따라 하다 보니 테스트 부분으로 이동하는 링크가 깨진 것을 알게 되었다. <h3>의 id를 Markdown에서 자동으로 생성해주는데 문서에 추가해놓은 주석 때문에 뒷부분 공백까지 id로 생성되어서 anchor가 깨진 것이라 너무 간단한 수정이지만 PR을 만들어 올리고 바로 머지되었다.

2. badges/shields에 GitHub Sponsors 배지 추가

GitHub Sponsors는 개발자나 조직을 후원할 수 있도록 GitHub이 제공하는 서비스인데 스폰서 배지를 만들어달라는이슈가 있었다. 우리나라에서는 못 쓰지만 스폰서는 관심 있는 서비스기도 해서 배지를 만들기 시작했다.

배지 구조를 알아야 했는데 하나하나 처음부터 다 해볼 수는 있어서 비슷해 보이는 GitHub fork와 tag 배지를 참고해서 작성했다. 스폰서 데이터가 GitHub GraphQL API의 Sponsorable에서 제공하고 있다는 것을 확인하고 GitHub GraphQL을 사용한 배지를 참고해서 작성했다.

사용자나 조직명을 입력하면 스폰서의 수를 가져와야 했기에 아래와 같은 GraphQL 쿼리를 작성했다.

query($user: String!) {
  repositoryOwner(login: $user) {
    ... on User {
      sponsorshipsAsMaintainer {
        totalCount
      }
    }
    ... on Organization {
      sponsorshipsAsMaintainer {
        totalCount
      }
    }
  }
}

간단한 쿼리지만 GraphQL을 별로 사용 안 해봐서 시간이 꽤 오래 걸렸다. 익숙해 지면 정말 편하게 쓸 수 있을 것 같은데 인터페이스로 표시된 Sponsorable을 어떻게 쿼리해야 하는지 몰라서 여기서 시간을 많이 허비했다. 주말에 작업하고 있었는데 회사에 최근 GraphQL을 도입했기 때문에 하마터면 프론트엔드팀 슬랙에 문의를 남길뻔했다. 그래도 몇 시간 고생하다가 조회하는 방법을 찾아내서 작성을 끝냈다. 다 만들고 나니 GraphQL 감이 좀 왔다.

배지랑 테스트는 어느 정도 작성했기 때문에 로고를 표시해야 하는데 Shields는 simple-icons에서 가져다 쓰도록 구성되어 있는데 여기에 Sponsors에 맞는 로고는 없었다. 마침 몇 개의 로고는 저장소에 포함되어 있길래 GitHub이 제공하는 공식 버튼에서 스폰서 로고의 SVG를 추출해서 가져왔다.

그렇게 주말 내내 완성해서 PR을 올렸다. 올리니 가능하면 로고를 저장소에 넣지 않는다고 simple-icons에 아이콘을 넣어달라고 해서 이게 말이 스폰서 로고지 사실상 그냥 하트 아이콘이기 때문에 simple-icons에서 받아줄지 모르겠다고 했다. 그 부분은 동의하지만, simple-icons에 시도는 해봐도 될 것 같다고 하면서 Shields에서는 그전까지 GitHub 로고를 임의로 사용하자고 해서 다시 수정해서 올리고 내가 코드를 다 이해 못 해서 불필요하게 들어간 부분을 피드백 받아서 수정했다.

일주일 정도 걸려서 머지가 되었고 Shields 사이트에서 배지를 가져다 쓸수 있게 잘 표시되고 있다.

3. simple-icons/simple-icons에 GitHub Sponsors 로고 추가

simple-icons는 Hacktoberfest에 참여하는 저장소가 아니었지만, 위에서 배지를 작업하면서 나온 Sponsors 로고를 simple-icons 형식에 맞게 수정해서 PR을 올렸다. SVG 로고를 주로 관리하는 프로젝트다 보니 이것저것 맞춰야 하는 게 많았는데 보통 SVG를 제플린 등에서 디자이너가 만든 거 추출해서 쓰거나 온라인에서 구해다 썼기 때문에 각 값의 속성을 다 알지는 못했다. 그래서 simple-icons의 가이드라인에 맞추는데, 꽤 시간이 걸렸다.

그냥 하트 아이콘을 과연 받아줄 것인가 하는 의구심을 가지고 PR을 올렸는데 실제로 올리자마자 이게 브랜드 로고인지 simple-icons에 넣어야 하는지에 대한 논의가 시작되었다. CI에서 Lint도 깨져서 수정요청이 있었는데 초기 댓글들이 이건 하트라서 안 넣는 게 좋을 것 같다는 얘기로 시작되며 다른 메인테이너들의 의견을 묻고 있었기 때문에 넣기로 합의되면 lint 실패를 수정하겠다고 하고 기다리고 있었다.

메인테이너들은 인기 있는 브랜드의 아이콘만 받는다면서 회의적인 입장이었는데 오히려 다른 사람이 등장해서 인기의 기준이 뭐냐면서 스폰서 아이콘 넣어야 한다고 설명하기 시작했다. simple-icons에는 GitHub Actions의 아이콘도 있는데 GitHub에 Sponsors 전용 페이지는 있지만, Actions는 없다고 설득하기 시작했고 메인테이너가 설득되어 나한테 Lint 오류를 수정해 달라고 요청을 했다.

Lint 오류는 아이콘이 정확히 가운데 오지 않은 문제였는데 <path>를 직접 수정해서 맞추는 방법을 몰라서 여러 에디터를 오가다가 Boxy SVG가 잘 만들어져 있어서 여기서 크기랑 간격을 맞추었더니 Lint를 통과할 수 있었다. 수정한 지 2주 정도가 되었지만, 아직 머지는 해주지 않고 있다. 머지되면 Shields에서 GitHub 로고 사용하던 것도 스폰서 로고로 바꾸는 PR을 올릴 수 있을 것 같다.

4. github/training-kit의 한국어 언어 코드 수정

GitHub에서 토픽으로 저장소를 찾다가 GitHub에서 직접 Git Cheat Sheets를 관리하는 저장소를 발견했다. PDF 생성이 자동화되지 않았는지 관리가 잘되는 것 같진 않았지만 들어가서 구경하다가 한국어 치트시트의 폴더명이 kr로 되어 있는걸 우연히 발견했다. ISO 639에 따르면 한국어의 언어 코드는 ko이고 kr는 국가 코드이다.(사실 많이들 헷갈리곤 한다.)

이슈가 만들어져 있던 것은 아니지만 명백히 잘못된 부분이라서 PR을 올렸고 바로 머지가 되었다.

5. lensapp/lens의 리비전 정렬 수정

Lens는 Kubernetes 클러스터를 관리할 수 있는 데스크톱 앱이다. kubectl을 주로 쓰긴 하지만 Lens도 같이 사용하고 있는데 Lens를 인수한 Mirantis한테서 다음과 같은 메일을 받았다.

사용하는 프로젝트에 기여하면 더 좋으니까 들어가서 할만한 이슈가 있나 살펴보다가 hacktoberfest 라벨이 붙은 이슈 중에 리비전 소팅이 제대로 되지 않는다는 이슈을 발견했다. 리비전이 숫자로 정렬되어야 하는 데 문자열로 인식되어서 1, 11, 2로 정렬이 되고 있었다.

수정할만할 것 같아서 로컬에 개발환경을 설정하고 프로젝트를 돌려보면서 리비전과 관련된 부분을 찾아가기 시작했다. 사실상 Kubernetes API를 이용하는 React 앱이었고 React를 잘 모르지만, 로그 찍어가면서 한참 보고 나니 관련된 부분을 찾을 수 있었다. TypeScript를 쓰고 있었는데 HelRelease의 revision 타입이 number로 지정되어 있음에도 실제로 값을 받아왔을 때는 문자열로 되어 있었다. React로 모르지만, TypeScript도 모르기 때문에 정확한 원인과 이유를 알 수 있었지만, API에서 값을 문자열로 주고 있었기 때문에 getter에서 Integer로 변환해서 돌려주도록 변경하니까 잘 동작했다. 테스트를 끝내고 PR을 올렸다.

다른 PR은 머지해 주는데 내 PR은 댓글도 안 달아줘서 초조하게 기다리던 차에 누가 이건 TypeScript에서 Object.assign에서 타입 검사가 제대로 되지 않게 된 이슈라고 생성자에서 추가로 parseInt를 해주면 된다는 댓글이었다.

너무 기다렸던 탓일까 나는 이 사람이 메인테이너라고 생각하고 있었고 실제로 해보니까 문제가 잘 고쳐졌다. 좀 편법 같은 느낌이 있어서 spread operator로 해보려고 했는데 이건 잘 안되었고 TypeScript를 잘 모르니 그냥 메인테이너가 안내해 준 거니 그대로 PR을 수정해서 업데이트했다.

며칠 뒤에 보니 다른 메인테이너가 PR을 하나 링크 걸었길래 살펴보니 나한테 댓글 단 사람이 댓글 후 2~3시간 뒤에 내 PR과 똑같은 PR을 올려놨다. 나도 댓글을 보고 그대로 수정했으니 당연히 내용은 같아졌고 그때서야 그 사람이 메인테이너가 아닌걸 알았다. 자기가 올릴 거면 왜 나보고 수정하라고 해서 시간 소비하게 했나 하는 억울함이 있었지만 난 알려준 대로 수정만 했기 때문에 "댓글 단 사람의 PR을 머지하는게 맡는 것 같다"고 댓글을 남겼다.

"시간 많이 썼는데 아쉽네"했더니만 메인테이너가 이건 Object.assign문제와는 관련 없고 내가 처음 수정했던 게 더 적절하니까 커밋 다시 리버트해달라고 요청이 와서 바로 수정하고 곧 머지가 되었다. 나중에 odyss님이 알려주셔서 알게 되었는데 Object.assign에서도 타입검사를 할 수 있다.

복잡하게 흘러갔지만 결국은 내 커밋이 Lens에 들어갔다. 근데 머지까지 다 하고 보니 Lens는 Hacktoberfest에 옵트인된 프로젝트가 아니다. 규칙을 잘 이해 못 했는지 저장소에 hacktoberfest 토픽이 달리지 않고 hacktoberfest 라벨이 달린 이슈는 있지만, PR에 hacktoberfest-accepted를 달아주진 않아서 결국 Hacktoberfest의 PR로 카운트되지 않았다. 결과적으로 Mirantis한테 낚였는데 요청하기도 뭐해서 커밋 들어간 것으로 만족했다.

6. github/training-kit의 checkout을 switch/restore로 수정

최근 새 버전에 맞게 git checkout 대신 switch/restore 사용하기라는 글도 썼는데 앞에서 github/training-kit의 언어 코드를 보다가 치트시트가 다 checkout으로 되어 있는 것을 발견했다.

lens가 카운팅 되지 않아서 PR이 하나 더 필요했기 때문에 이젠 Git에서 switch/restore를 권고하는 것으로 이해하고 있기에 이 부분도 모두 switch/restore로 변경했다. 여러 언어로 되어 있어서 번역기 돌리면서 여기가 switch/restore로 바꿔도 되는지 확인해 가면서 수정해서 PR을 올렸다.

금방 머지될 줄 알았는데 GitHub 내부팀과 확인해봐야 한다고 해서 아직 대기 중이다.

Hacktoberfest 결과

PR이 머지되어도 문제를 방지하기 위해서인지 2주간 기다린 뒤 카운팅 되는데 4개가 다 조건에 맞아서 티셔츠를 신청할 수 있게 되었다.

마지막 1개의 PR은 Hacktoberfest Seoul에 발표자료를 올리면서 생긴 PR이라서 이거 외에 4개로 채우고 싶었는데 결국, 이 PR까지 포함해서 4개의 조건이 되었다. 그래도 다른 프로젝트에 4개 이상 PR을 올린다는 목표는 충족되었기 때문에 10월 말에 하나 더 올리려다가 이 정도로 마무리했다. 항상 그렇듯이 티셔츠는 기억이 가물가물해질 내년 1월 정도에나 올 것 같다.

이런 오픈소스 기여 행사로는 곧 12월에 24 Pull Requests가 있는데 이건 크리스마스까지 매일 하나씩 올리는 거라 Hacktoberfest 보다는 훨씬 힘들다.