2024.07.01 프로그래머스 - 오픈소스 생태계 1

오픈소스 생태계 - 1

오픈소스 문서의 구조

오픈소스 구조에 정답은 딱히 없다.

기본 문서 ⭐

• LICENSE.md
  • 오픈소스 라이센스 전문 명시 문서
• README.md
  • 프로젝트 코드의 목적, 사용방법, 설명문서
• COPYRIGHT
• Contribute
  • 기여자를 원할 경우
• CHANGELOG
• PR 규칙 문서
• Code of Conduct
  • 커뮤니티 행동 강령

README 문서

README 문서는 사용자가 오픈소스를 접했을 떄 가장 처음 보게 되는 문서다.

사용자의 이해를 돕기 위해 아래 내용을 필수적으로 포함하면 좋다.

• 프로젝트의 목적과 용도
  • 프로젝트가 무엇을 위해 만들어졌는가
  • 어떤 문제를 해결할 수 있는 프로젝트인가
  • 이 프로젝트는 왜 유용한가?
  • 어떤 사람들을 대상으로 이 프로젝트를 만들었는가?
  • 프로젝트의 작동 방식
• 프로젝트 시작 방법
  • 프로젝트 설치, 사용 조건 (환경)
  • 설치방법, 테스트방법,
  • 설치 가이드
• 저작권, 라이선스 정보
  • 어떤 라이센스로 배포되는지
  • 상세한 라이센스 정보를 확인할 수 있는 곳
  • 프로젝트 사용에 대한 제약조건
• 외부 리소스 정보
  • 각 외부 리소스의 출처 및 배포 라이센스
• 기여방법
  • 기여자가 기여를 하는 방식을 규정하여, 정형화된 기여문화를 만든다.

Code Of Conduct 문서

• 커뮤니티 행동강령!
• 커뮤니티의 목적과, 방향성, 바람직한 행동방법에 대한 기술 문서
• 좋은 커뮤니티를 만들기위해서는 필수로 작성해야하는 문서

Code Of Conduct 문서가 필요한 이유

• 건설적인 기여자, 커뮤니티 이용자 들의 태도를 촉진한다.
• 문제상황에 대한 조치를 취할 수 있다.
• Organizer들의 부담을 줄여준다.

필수적으로 기입되어야할 내용

• 효력이 발생하는 정확한 주체 (github issue 내, 커뮤니티 게시판 등)
• 누구에게 적용되는지
• 위반 시에 일어날 수 있는 일
• 위반 사례를 신고할 수 있는 방법

Github 속 기여를 위한 부분

Issues

업무 또는 협업, 버그 발견, 개선사항 등에 대한 자세한 사항을 명시하여

발행하는 게시판 개념

• 해당 Repo 관리자는 해당 issue를 읽고 프로젝트의 버그나 결함을 발견할 수 있다.
• 다른 사용자들이 같은 오류를 발견했을 경우에 대해 Issue내에서 이미 발생했던 오류를 검색할 수 있다.
• 프로젝트 내의 Issue Contribute에 대한 자세한 설명을 읽고 작성해야 한다.(문서가 있을 시 )
• 어디서나 그렇듯, 얘기하고자 하는 주제에 대해 구체적으로 조리있게 작성해야 한다.
• Open 된 Issue는 사용자 또는 관리자에 의해 해결되고 난 뒤 Close 된다.
  • reOpen으로 다시 열 수도 있다.
• issue_template.md 파일을 만들어 Issue에 대한 템플릿을 적용할 수 있다.
  • 일관된 형식의 Issue 문서를 관리할 수 있다.

PR : Pull Request

새로운 코드 변경사항을 원본 소스코드에 병합하기 위해 제안하는 것을 의미

• base : pull 요청을 받게 될 브랜치
• compare : base 로 요청을 보낼 브랜치
• title : PR 제목

• Description : PR에 대한 설명 및 이유 등 자세한 사항을 설명할 수 있는 부분

• 프로젝트 관리자(Organizer) 측에서 해당 PR을 확인 후, 코드리뷰를 진행하여 이상이 없으면, pull 요청한 브랜치에 병합을 진행한다.
  • 프로젝트당 설정은 다르지만 최소 1명 이상의 리뷰어가 리뷰를 끝내야 병합이 가능한 설정들이 있다.