커뮤니티

기여하기

소스 코드에 기여하고, iText 7 커뮤니티가 더욱 발전할 수 있도록 도와주세요!

iText 7 Community에 기여

소스 코드에 기여하고 지금보다 iText 7 Community가 더욱 발전할 수 있도록 도와주세요! 다음과 같은 가이드라인을 준수해주세요.

질문이나 문제가 있으신가요?

iText 7 Community 사용 방법에 대한 질문이 있으시다면 Stack Overflow에 문의하세요.

지원 계약을 맺은 고객이라면 JIRA 및 iText 개발자에게 직접 문의하실 수 있습니다.

이슈를 발견하셨나요?

소스 코드에서 버그를 발견했거나 문서에서 오류를 발견한 경우, 수정 사항과 함께 Pull 요청을 제출해주세요.

아래의 제출 가이드라인을 참조하세요.

기능을 구현하고 싶으신가요?

새 기능을 구현하고 싶다면 어떤 종류의 변경 사항인지 생각해보세요.

  • 중요한 변경 사항을 프로젝트에 기여하고 싶다면 서로 잘 협조하여 노력하고, 중복 작업이 발생하지 않도록 예방하며, 프로젝트에 성공적으로 받아들여질 만한 변경 사항을 구현할 수 있도록 먼저 협의를 거쳐야 합니다. community@itextpdf.com으로 문의해주세요.
  • 사소한 변경 사항GitHub 리포지토리Pull 요청으로 작성하여 제출할 수 있습니다.

제출 가이드라인

질문 또는 이슈 제출

질문이나 이슈를 제출하기 전에 Stack Overflow를 검색해보세요. 질문에 대한 답변이 이미 등록되어 있을 수 있습니다.

이슈가 버그이고 아직 보고되지 않은 것 같다면 Stack Overflow에 질문을 올려 실제로 버그인지, 코드상의 오류가 아닌지 확인을 받으세요. 중복 이슈를 보고를 예방한다면 이슈를 수정하고 새 기능을 추가하는 노력을 극대화하는 데 도움이 됩니다. 다음의 정보를 제공하면 이슈가 신속히 처리될 가능성이 커집니다.

  • 좋은 질문을 하는 방법
  • 이슈 개요 - 오류가 발생한다면 전체 스택 추적이 있으면 도움이 됩니다.
  • 사용 사례에 대한 의도 - 왜 버그에 해당하는지 설명해주세요.
  • iText 버전 - 회귀입니까?
  • 운영 체제 - Windows, Linux 또는 Mac의 문제입니까?
  • 오류 재현 - 간단한 독립적인 적절한(컴파일 가능한) 예제(최소한의 완전하고 검증 가능한 예제)를 제공해주세요.
  • 관련 이슈 - 이전에 유사한 이슈가 보고된 적이 있나요?
  • 수정 제안 - 버그를 직접 수정할 수 없으면 문제의 원인(코드 줄 또는 커밋)을 알려주세요.
  • 질문 태그 - 검색할 수 있도록 itext7 태그를 질문에 추가하세요.

도움을 받았으면 다른 사람들도 도와주세요. 선행은 돌고 돕니다!

Pull 요청 제출

pull 요청을 제출하기 전에 다음의 가이드라인을 고려하세요.

  • GitHub에서 제출과 관련된 공개 또는 비공개 pull 요청을 검색합니다. 중복 요청은 하지 않는 것이 좋으니까요.
  • 제안된 변경 사항이 개발 브랜치에서 이미 해결한 것은 아닌지 확인합니다.
  • 변경하는 모든 파일에 대해 별도의 pull 요청을 보내지 마세요.
  • 20개 이상의 중요한 코드 줄에 대해 pull 요청을 보내기 전에 iText Contributor License Agreement(iCLA)에 서명해주세요(중괄호와 다른 구문적 장식은 계산하지 않습니다). 이 계약 없이는 코드를 수락할 수 없습니다.
  • GitHub에서 iText 리포지토리를 포크하세요.
  • iText 포크를 로컬 컴퓨터에 복제합니다.
  • 적절한 테스트 사례를 포함하여 변경 사항을 적용합니다.
  • iText의 코딩 규칙을 준수하세요.
  • 커밋 메시지 규칙에 따라 설명하는 커밋 메시지를 사용하여 변경 사항을 커밋합니다.
  • 이제 필요하거나 원할 경우, git rebase --interactive로 커밋을 수정하면 됩니다.
  • 로컬에 변경 사항을 구축하여 모든 테스트를 통과하는지 확인하세요.
  • 변경 사항을 GitHub 계정으로 푸시합니다.
  • GitHub에서 pull 요청을 생성합니다.

"헤드 포크"는 리포지토리가 되어야 하고 "기본 포크"는 iText7 공식 리포지토리가 되어야 합니다.

  • 변경 사항을 제안할 경우에는 다음 사항을 따라주세요.
    • 필수 업데이트 적용
    • 필요한 경우 인터랙티브 리베이스로 커밋을 수정
    • 테스트를 다시 실행하고 통과하는지 확인
    • GitHub 리포지토리로 푸시하여 pull 요청 업데이트

아주 간단합니다! 기여해주셔서 감사합니다.

pull 요청이 병합된 후

pull 요청이 병합된 후 포트를 안전하게 삭제하고 메인(업스트림) 리포지토리에서 변경 사항을 가져올 수 있습니다.

코딩 규칙

소스 코드에서 일관성을 확보하기 위해 작업 중에는 다음의 규칙을 잊지 말고 적용하세요.

  • iText에서는 Java로 개발한 다음, .NET으로 가져오므로 Java로 코드를 제출하는 것이 좋습니다. 그러나 .NET 포트로 좋은 pull 요청을 보내면 안 된다는 의미는 아닙니다.
  • 모든 Java 코드는 반드시 Java 7이어야 합니다. 죄송하지만 lambda 식이나 다른 Java 8 언어 기능은 지원되지 않습니다.
  • 모든 기능 또는 버그 수정은 하나 이상의 유닛 테스트검증을 거쳐야 합니다.
  • 모든 공개 API 메서드는 JavaDoc으로 기록해야 합니다. iText의 API 기록 방법을 살펴보려면 기존 javadocs를 참조하세요.
  • Oracle의 Code Conventions for the Java Programming Language에 포함된 규칙을 준수하고 그에 더해 다음의 규칙을 추가했습니다.
    • 모든 코드를 100자로 줄 바꿈

Git 커밋 가이드라인

git 커밋 메시지의 서식 지정에 관한 가이드라인이 준비되어 있습니다. 이 가이드라인을 따르면 프로젝트 기록을 검토할 때 따라 읽기 쉽고 가독성 좋은 메시지를 작성할 수 있습니다. 또한, iText 7 Community 변경 로그를 작성할 때도 git 커밋 메시지가 사용됩니다.

이 가이드라인은 Chris Beams의 블로그 게시물 How to Write a Git Commit Message에서 발췌하였습니다.

커밋 메시지 서식

각 커밋 메시지는 제목, 본문꼬리말로 구성됩니다.

<제목>
<빈 줄>
<본문>
<빈 줄>
<꼬리말>

커밋 메시지의 모든 줄은 72자 이내여야 합니다! 그래야 GitHub 및 다양한 git 도구에서 손쉽게 메시지를 읽을 수 있습니다.

제목

제목에는 변경에 대한 간단한 설명이 포함됩니다.

본문

꼬리말에는 중요한 변경 사항에 대한 정보가 포함되며, 이 커밋이 종결하고자 하는 JIRA 또는 GitHub 이슈를 참조하는 곳이기도 합니다.

iCLA 서명

pull 요청을 보내기 전에 iText Contributor License Agreement(iCLA)에 서명해주세요. 중대한 코드 변경 사항(중요 코드의 20줄 이상)을 제출하는 경우, 반드시 iCLA에 서명해야 합니다. 절차는 매우 간단합니다!

(디지털로) 서명해서 이메일, 팩스, 또는 우편으로 양식을 보내주시면 됩니다.

기여자 행동 규범

이 프로젝트는 기여자 행동 규범과 함께 공개되었습니다. 이 프로젝트에 참여하면 해당 약관을 준수하는 데 동의하게 됩니다.

Stack Exchange 네트워크에서 무료 지원을 제공하고 있으며, GitHub에서는 코드를 호스팅합니다. 이 서비스를 사용하면 다음의 약관을 준수하는 데 동의하게 됩니다.

오픈 소스 커뮤니티에 기여

소스 코드에 기여하고, iText 7 커뮤니티가 더욱 발전할 수 있도록 도와주세요! 

기여하기
문의

문의가 해결되지 않았습니까? 

저희가 도와드리겠습니다. 연락해 주시면 빠르게 답변해 드리겠습니다.

문의하기
최신 정보를 받아보세요

11,000명 이상의 가입자와 함께 새로운 제품, 업데이트, 팁, 기술 솔루션 및 기회에 대한 최신 정보를 받아보시면서 iText PDF 전문가가 되어보세요.

지금 구독하기