참여하기

참여하기 (Getting Involved)

Apache HBase는 사람들이 기여할 때 더 좋아져요. HBase에 기여하는 방법, 메일링 리스트·Slack·IRC 소통 채널, JIRA 사용법과 효과적인 이슈 보고 지침을 살펴볼게요.

출처: 문서

본문

Apache HBase는 사람들이 기여할 때만 더 좋아져요! Apache HBase에 기여하려고 한다면, JIRA에서 'beginner' 라벨이 달린 이슈를 찾아보세요. 이 이슈들은 HBase 기여자들이 가치 있다고 판단했지만 즉시 우선순위는 아닌, HBase 내부에 적응하기 좋은 이슈들이에요. 배경 지식은 dev 메일링 리스트의 What label is used for issues that are good on ramps for new contributors?를 참고해 주세요.

HBase에 코드를 제출하기 시작하기 전에 Developer Guidelines를 참고해 주세요.

Apache HBase는 아파치 소프트웨어 재단 프로젝트이므로, ASF가 어떻게 기능하는지에 대한 자세한 내용은 The Apache Software Foundation을 참고해 주세요.

메일링 리스트 (Mailing Lists)

dev-list와 user-list에 가입해 주세요. 메일링 리스트 페이지를 참고해 주세요. 질문을 올리고 — 다른 사람의 질문에 답하는 것을 도와주는 것도 — 권장돼요! 두 리스트 모두 다양한 경험 수준이 있으므로 인내와 예의가 권장돼요(주제를 벗어나지 말아 주세요).

Slack

Apache HBase 프로젝트는 공식 ASF Slack Workspace의 #hbase 채널을 실시간 질문과 토론에 사용해요. 아파치 프로젝트의 모든 committer는 채널에 직접 가입할 수 있고, 그 외 사람은 [email protected]로 메일을 보내 초대를 요청해 주세요.

IRC (Internet Relay Chat)

(참고: 우리 IRC 채널은 위 Slack 채널로 대체되면서 폐기된 것 같아요.)

실시간 질문과 토론을 위해 FreeNode IRC 네트워크의 #hbase IRC 채널을 사용해 주세요. FreeNode는 웹 기반 클라이언트를 제공하지만, 대부분의 사람들은 네이티브 클라이언트를 선호하며 각 운영체제에 여러 클라이언트가 제공돼요.

Jira

Jira에서 기존 이슈를 확인해 주세요. 새 기능 요청, 개선, 또는 버그라면 티켓을 등록해 주세요.

우리는 JIRA에서 여러 유형의 작업을 추적해요.

  • Bug: HBase 자체에 뭔가 고장난 경우.
  • Test: 테스트가 필요하거나, 테스트가 고장난 경우.
  • New feature: 새 기능에 대한 아이디어가 있는 경우. 먼저 메일링 리스트에 가져와 논의한 다음, 기능 요청 JIRA에 추가할 설계 명세를 작성하는 것이 좋아요.
  • Improvement: 기능은 존재하지만 수정하거나 확장할 수 있는 경우. 먼저 메일링 리스트에 가져와 논의하고, 다른 사람들이 그 개선에 관심을 보이면 논의를 요약하거나 링크하는 것이 좋아요.
  • Wish: 새 기능과 비슷하지만, 스스로 구체화할 배경 지식이 없을 수 있는 것.

버그와 테스트가 최우선순위이며 실행 가능해야 해요.

효과적인 이슈 보고 지침 (Guidelines for reporting effective issues)

  • 중복 검색하기: 여러분의 이슈는 이미 보고되었을 수 있어요. 다른 사람이 요약을 다르게 표현했을 수 있으니 잘 살펴보세요. 또한 메일링 리스트를 검색해 보세요. 거기에 여러분의 문제와 해결 방법에 대한 정보가 있을 수 있어요. 메일링 리스트에서 이미 논의되고 해결된 것을 이슈로 등록하지 마세요. 단, 해결에 강하게 동의하지 않고 이슈를 진행하는 데 기꺼이 도움을 주려는 경우는 예외예요.

공개적으로 논의하기: 발견한 것을 메일링 리스트로 논의하고 놓친 것이 있는지 확인해 보세요. 백채널(back channels) 사용은 피하세요. 그래야 프로젝트 전체의 경험과 전문성을 활용할 수 있어요.

남을 대신해 등록하지 마세요: 모든 맥락이 없을 수 있고, 실제로 버그를 겪는 사람만큼 끝까지 추진할 동기도 없어요. 장기적으로는 다른 사람이 자신의 이슈를 등록하도록 격려하는 것이 더 도움이 돼요. 이 자료를 가리켜 주고 처음 한두 번은 도움을 주겠다고 제안해 보세요.

좋은 요약을 작성하세요: 좋은 요약에는 문제에 대한 정보, 사용자나 개발자에게 미치는 영향, 코드 영역이 포함돼요.

좋은 예: Address new license dependencies from hadoop3-alpha4 개선 여지가 있는 예: Canary is broken 나쁜 제목을 쓰면 다른 사람이 당신을 위해 다시 써줄 거예요. 그 시간이 이슈에 쓰이지 않아도 되는 시간이에요.

설명에 맥락을 제공하세요: 이를 여러 부분으로 생각하는 것이 좋아요.

무엇이 일어나거나 일어나지 않나요? 어떻게 당신에게 영향을 주나요? 다른 사람이 어떻게 재현할 수 있나요? "수정된" 상태는 어떤 모습인가요? 이 모든 것의 답을 알 필요는 없지만, 가능한 한 많은 정보를 주세요. 문제를 일으켰을 것으로 생각되는 Git 커밋 SHA나 문제가 처음 나타났을 것으로 보이는 builds.apache.org의 빌드 실패 같은 기술 정보를 제공할 수 있다면 그 정보를 공유해 주세요.

모든 관련 필드를 채우세요: 이 필드들은 필터링, 분류, 검색에 도움을 줘요. 하나의 버그, 하나의 이슈, 하나의 패치: 백포트(back-porting)를 돕기 위해 이슈나 수정을 여러 버그로 나누지 마세요. 가능하면 가치를 더하세요: 이슈를 등록하는 것도 좋지만, 가능한 한 많은 정보를 제공하고, 트리아지와 질문 답변에 기꺼이 응하고, 잠재적 수정을 테스트하려는 의지가 있다면 더 좋아요! 우리는 당신이 원하는 만큼 빨리 당신의 이슈를 고치고 싶어요. 수정하지 않아도 화내지 마세요: 시간과 자원은 유한해요. 어떤 경우에는, 특히 엣지 케이스이거나 해결 방법이 있으면, 이슈를 수정할 수 없거나(또는 수정하지 않기로 선택) 할 수 있어요. 고쳐지지 않아도 JIRA는 그 공개 기록이며, 미래에 비슷한 이슈를 겪는 다른 사람들에게 도움이 될 거예요.

이슈 작업하기 (Working on an issue)

초보자로 착수할 수 있는 기존 이슈를 확인하려면 JIRA에서 'beginner' 라벨이 달린 이슈를 검색해 주세요.

JIRA 우선순위:

  • Blocker: 이슈가 확실히 데이터 손실이나 클러스터 불안정을 일으킬 경우에만 사용해야 해요.
  • Critical: 설명된 이슈가 어떤 경우에는 데이터 손실이나 클러스터 불안정을 일으킬 수 있는 경우.
  • Major: 비극적이지는 않지만 중요한 이슈. 예를 들어 많은 필수 기능을 추가할 클라이언트 API 업데이트나 데이터 손실을 일으키지 않지만 고쳐야 할 중요한 버그.
  • Minor: 유용한 개선과 성가시지만 해롭진 않은 버그.
  • Trivial: 유용하지만 일반적으로 표면적인 개선.

Jira 댓글의 코드 블록:

Jira에서 흔히 쓰이는 매크로는 {code}예요. 태그 안의 모든 것이 미리 서식화(preformatted)돼요. 이 예시처럼요.

{code}
code snippet
{code}

더 알아보기 (Learn more)

개발에 참여하고 빌드하는 방법은 Developer Guidelines와 Building Apache HBase 문서를 보시길 권해요.