Line 오픈소스 기여 과정 살펴보기

pengooseDev·2024년 3월 9일

GDG Songdo contribute opensource 오픈소스 오픈소스 기여하는 법

지인분이 GDG 오픈소스 프로젝트에서 Google 오픈소스에 기여하신 뒤 컨퍼런스에서 발표를 하셨다.
그 분의 추천으로 인제님이 이끄시는 GDG Songdo 오픈소스 프로젝트 3기에 참여하게 되었다.

이 글은 오픈소스를 처음으로 기여하는 개발자들에게 도움을 주고자, 스터디 및 오픈소스 기여 과정에서 얻은 지식들을 정리한 것이다.

아래의 Flow를 따라가며 첫 오픈소스 기여를 시도해보자 🥳

1) Issue 찾아보기

PR을 할 수 있는 Issue를 찾는 방법에는 크게 2가지가 있다.

1-1) 기존 Issue를 할당받는 방법

Issue 카테고리에서 issue를 할당받는 방식이다.
아래의 조건을 만족하는 경우 PR을 생성하기 좋은 Issue이다.
1. maintainer와 방향성의 토의가 이루어져있는 경우.
2. 문제가 발생하는 조건에 대해 상세하게 기술되어있는 경우.
3. 개선 방향성을 제시해둔 경우.
4. 히스토리 파악을 위한 커밋 및 PR을 남겨둔 경우.

1-2) 직접 Issue를 생성하는 방법

코드를 직접 훑어보며 개선점을 직접 제시하는 것도 좋다.

> Issue #699

커스텀 에러에서 name field를 사용하지 않아, 이에 대한 개선을 제안하였다.

2) 이슈 할당받기

Project Maintainer와 협의가 되었다면, Issue를 할당받게 된다.

명시적으로 할당받지 않더라도 Maintainer와 다른 개발자들에게 적절하게 어필한 뒤, 시작하는 것도 좋아보인다.

3) 코드 컨텍스트 파악하기

코드를 작성하기 전, 해당 코드의 Context와 history를 파악해야한다. 필자는 아래의 방식으로 코드를 이해하였다.

UnitTest가 구현되어있는 경우, 이를 기반으로 로직 이해하기.

commit history, PR을 확인하여 history 파악하기.

코드에 대한 의존성을 파악하기.

위 사항들을 진행한 결과 변경해야할 부분과 추가적으로 작성해야할 테스트코드의 위치 및 컨벤션을 쉽게 익힐 수 있었다.

4) 문제 해결하기

이제 코드를 작성할 시간이다.
아래의 것들을 주의하며 코드를 작성하였다.

네이밍 컨벤션을 잘 지키고 있는가?

코드 컨벤션을 잘 지키고 있는가?

커밋 컨벤션을 잘 지키고 있는가?

이미 추상화 되어있는 것을 또 다시 추상화 하고 있지 않은가?(Type 포함)

테스트 코드나 문서도 함께 변경되어야 하는가?

코드를 작성하다보면, 내가 이걸 바꿔도 되나?라는 의문이 드는 부분이 발생하게 된다.
그럴땐...

5) 피드백 받기

조금이라도 애매한 부분은 Issue 및 PR에서 Maintainer와 함께 논의하는 것이 중요하다고 생각한다.

피드백 요청 예시 :

물론, Maintainer에게 피드백을 받을 수 없는 경우, 과감한 변경은 삼가는 것이 좋아보인다.

6) PR 생성하기

PR을 생성할 때, 정해진 템플릿에 맞춰 PR을 생성한다.
정해진 템플릿이 없다면 이전 PR들을 확인하여 따르는 것이 편하다.

PR Convention 맞추기(제목, 템플릿 등)

해당 PR이 어떤 Issue를 기반으로 생성된 PR인지 명시하기

해당 PR이 어떤 내용을 담고있는지 명시하기

> PR [#739]

7) Contribute 필수 요소 확인하기

또한, 변경사항이 merge되기 이전, 아래의 요소들을 확인해야한다.

build 확인하기

테스트 통과 확인하기

CI test 확인하기

Contribute 요구사항 확인하기

권리 계약서 서명하기(요구하는 경우에만)

보통 아래처럼 문서화 되어있는 경우가 대부분이다.

Contributer에게 제공되는 문서가 있다면, 해당 문서를 잘 읽어보자!

8) 4,5 단계 반복. 그리고 merge

필자의 경우 Maintainer분이 활발하게 피드백을 진행해주셨기에 수월하게 PR을 merge할 수 있었다.

Line에 관심이 많아 여러 프로젝트를 살펴봤었는데, 이렇게 기여까지 하게 되어 기쁠따름이다. 🥳

> Issue

> PR(Refactor Error)

+9) 추가 Issue 및 PR 생성하기

코드를 작성하다보니 UnitTest에 대한 개선 사항이 보여 추가적으로 개선을 제안했다.

(Mocha에서는 test.each 메서드를 지원하지 않아 forEach를 사용)

빠르게 merge 되었다.

> PR(Refactor UnitTest)

  it("succeed with pre-parsed string", async () => {
    await http().post(`/mid-text`, {
      events: [webhook],
      destination: "Uaaaabbbbccccddddeeeeffff",
    });
    const req = getRecentReq();
    deepEqual(req.body.destination, "Uaaaabbbbccccddddeeeeffff");
    deepEqual(req.body.events, [webhook]);
  });

  it("succeed with pre-parsed buffer", async () => {
    await http().post(`/mid-buffer`, {
      events: [webhook],
      destination: "Uaaaabbbbccccddddeeeeffff",
    });
    const req = getRecentReq();
    deepEqual(req.body.destination, "Uaaaabbbbccccddddeeeeffff");
    deepEqual(req.body.events, [webhook]);
  });

  it("succeed with pre-parsed buffer in rawBody", async () => {
    await http().post(`/mid-rawbody`, {
      events: [webhook],
      destination: "Uaaaabbbbccccddddeeeeffff",
    });
    const req = getRecentReq();
    deepEqual(req.body.destination, "Uaaaabbbbccccddddeeeeffff");
    deepEqual(req.body.events, [webhook]);
  });

Refactored


  describe("Succeeds on parsing valid request", () => {
    const testCases = [
      {
        describe: "pre-parsed string",
        endpoint: `/mid-text`,
      },
      {
        describe: "pre-parsed buffer",
        endpoint: `/mid-buffer`,
      },
      {
        describe: "pre-parsed buffer in rawBody",
        endpoint: `/mid-rawbody`,
      },
    ];

    testCases.forEach(({ describe, endpoint }) => {
      it(describe, async () => {
        await http().post(endpoint, {
          events: [webhook],
          destination: DESTINATION,
        });

        const req = getRecentReq();
        deepEqual(req.body.destination, DESTINATION);
        deepEqual(req.body.events, [webhook]);
      });
    });
  });