Bitcoin Core에 제출된 PR을 검토하는 방법

저자: 존 아탁

출처: https://jonatack.github.io/articles/how-to-review-pull-requests-in-bitcoin-core

소개

코드 검토와 테스트는 아마도 비트코인 ​​코어에 기여하는 가장 좋은 시작 방법일 것입니다.

오랜 기간 비트코인 ​​코어 개발자들이 광범위한 검토 및 테스트를 자주 언급하는 이유는 다음과 같습니다.

• 자원 병목 현상, 그리고
• 이는 학습하고, 코드 기여를 시작하고, 커뮤니티에 자신의 발자취를 남기는 가장 효과적인 방법입니다.

시작하기 전에

이 가이드는 다음 문서를 기반으로 작성되었습니다.

1. " 비트코인 코어에 기여하기: 개인적인 경험 ", 존 뉴베리 저 (2017)
2. 피에르 로샤르 의 저서 " 비트코인의 기술적 측면 이해하기 "(2018).
3. 제레미 루빈 의 하드코어 워크숍 영상 / 녹취록 / 슬라이드 (2018).

용어

ACK와 NACK : 이들의 정의와 유래는 여기 와 여기에서 확인할 수 있습니다.

사소한 문제: 보통 막힘을 유발하지 않는 아주 작은 문제.

PR : " 풀 리퀘스트(pull request )"의 줄임말이며, "머지 리퀘스트(merge request)"라고도 합니다. 소스 코드 저장소의 코드나 문서를 변경하자는 제안입니다.

WIP 는 " 진행 중인 작업(work in progress )"의 약자입니다.

일반 교육

신입으로서 우리의 목표는 친절하고 겸손한 태도로 최대한 많은 것을 배우면서 가치를 더하는 것입니다. (물론 이러한 목표는 신입에게만 해당되는 것이 아니며, 오히려 이 과정은 끝이 없습니다.)

좋은 접근 방식은 그것을 통제할 수 있는 것으로 여기기보다는 "어떻게 하면 모든 사람에게 가장 도움이 될 수 있을까?"라고 스스로에게 묻는 것입니다.

새로운 기여자들 대면 가장 어려운 문제 중 하나는 코드베이스의 방대함과 그와 관련된 기술적 복잡성입니다.

모르는 것이 있을 수 있다는 점을 명심하세요. 오랜 경력을 가진 개발자들은 다년간의 경험과 전문적인 배경을 가지고 있습니다. 커뮤니티는 풍부한 집단적 지식과 경험을 축적해 왔습니다. 당신의 새로운 아이디어가 이미 여러 번 언급되고 고려되었을 수도 있다는 점을 기억하세요.

기여자 및 유지 관리자는 시간과 에너지가 제한되어 있다는 점을 기억해 주십시오. 도움을 요청할 때는 신중하고 정중하게 행동해 주시기 바랍니다. 목표는 요청하는 것보다 더 많이 베풀고, 방해하는 것보다 더 많이 도와서 작업 속도를 높이는 것입니다.

가능한 한 스스로 문제를 해결하려고 노력하고, 적어도 다른 사람의 시간을 충분히 존중하십시오.

#bitcoin-core-dev 라이브 채팅방과 bitcoin-dev 메일링 리스트를 팔로우하세요.

더 주목할 만한 IRC 채널은 여기에서 찾을 수 있습니다 .

시작하기 전에도 대량 시간을 투자해야 합니다.

• 기여 프로세스와 가이드라인을 이해하려면 코드베이스의 문서(특히 " 기여 가이드라인 ", " 개발자 노트 ", " 생산성 노트 ")를 읽는 것(더 나아가 문서 와 테스트 코드베이스 의 모든 내용)만으로는 부족합니다. #bitcoin-core-dev IRC 채널에서의 상호 작용과 코드베이스에서 진행되는 코드 리뷰에도 주의를 기울여야 합니다.
• 정기적으로 기고하는 사람들에 대해 알아보세요. 그들이 무엇을 하는지, 무엇을 좋아하는지, 무엇을 원하는지, 그리고 피드백을 어떻게 받아들이는지 파악하세요.

많은 신규 사용자가 바로 PR(풀 리퀘스트)을 제출하지만, 이는 가치 있는 검토를 기다리는 수백 개의 PR에 하나 더 추가될 뿐입니다. 기존 PR을 검토하고 어떤 유형의 PR이 더 유용한지 파악하여 점차 전체적인 그림을 이해하는 것이 훨씬 효과적입니다.

일반적으로 유용한 팁은 PR을 생성하기 전에 5~15개의 PR을 먼저 검토하는 것입니다.

파노라마

큰 그림이 사소한 오류, 철자 오류, 코드 스타일보다 훨씬 더 중요합니다.

포괄적인 검토 과정에는 여러 단계가 있습니다. "이 변화가 어떤 행동에 영향을 미칠까?" 또는 "이 변화는 안전한가?"는 "이것이 좋은 생각일까?"와는 다릅니다. 후자의 질문에 답하려면 더 많은 맥락이 필요하며, 이는 점차 배우게 될 것입니다. 이러한 질문들을 생각하는 것을 멈추지 말고, 이 단계에서의 검토를 포기하지 마십시오.

파노라마 사진에 대한 이해도를 높이는 방법:

• Chaincode Labs 학습 가이드를 완료하세요
• Chaincode Labs의 온라인 강좌를 신청하고 수강하는 것을 고려해 보세요. 이 강좌는 비트코인 ​​관련 일자리와 오픈소스 보조금을 찾는 신규 개발자들을 위한 검색 엔진 역할도 합니다. (이 프로그램은 강력히 추천합니다.)
• 비트코인 업그레이드 제안 (일반적으로 단수형으로 "BIP"라고 함)을 연구하고 정기적으로 검토하십시오.
• Bitcoin Optech Weekly 를 구독하고 해당 뉴스레터의 주제 페이지를 유용한 자료로 활용하세요.
• " 명령줄을 통해 비트코인 ​​배우기 "를 완료하세요

양보다 질을 추구하고, 심층적인 작업과 신속한 결과 사이에서 균형을 유지하십시오.

문서 작성은 중요합니다. 예를 들어, 각 구성 요소의 작동 방식과 상호 작용에 대한 요약, 명확하고 정확한 코드 문서, 함수에 부호가 있는지 여부에 대한 지침, Doxygen 문서 , 테스트 로그( info 및 debug 모두 포함) 등이 포함되어야 합니다.

테스트 커버리지 또한 중요합니다. 누락된 유닛 테스트 , 기능 테스트 , 퍼즈 테스트가 있다면 주저하지 말고 작성하여 개선하십시오.

겸손하고 친절한 기여자가 되어 주세요. PR을 검토하고, 테스트 및 유용한 수정 사항을 제안하고 , 코드 리베이스를 제안하고, 몇 달 동안 방치된 PR을 인수하는 것을 고려하는 등 PR 진행에 도움을 주세요. 간단히 말해서, 서로 돕도록 합시다!

바보

PR, 특히 아직 "WIP"로 표시된 PR의 경우, 사소한 디테일이나 코드 스타일에 지나치게 집착하지 마세요. 또한 PR이 생성된 직후, 작성자가 개념적 및 방법론적 합의를 구하는 단계(예: 일반적인 합의를 도출하는 단계)에 있을 때는 성급하게 세부적인 사항을 지적하지 않는 것이 좋습니다.

오랜 기간 참여해 온 사람들은 그러한 활동이 불쾌하다고 말했으며, 더욱이 그러한 활동은 프로젝트 내에서 여러분의 사회적 자본을 감소시킵니다. 사람들이 어떤 종류의 리뷰를 필요로 하는지, 그리고 언제 리뷰가 필요한지 이해하려고 노력하세요.

사소한 지적 사항에 대해 의견을 제시하기 가장 좋은 시기는 PR이 개념/방법에 대한 충분한 승인(즉, 합의)을 받은 후, 하지만 PR이 닫히고 "테스트 완료 승인"을 받기 전입니다. Pieter Wuille 이 IRC에서 말했듯 이, "PR에서 가장 답답한 점은 세부 사항/사소한 지적 사항/코드 스타일 등에 대한 의견은 대량 받았지만, 정작 PR의 개념이 좋은지 알 수 없는 것입니다."

사소한 오류나 코딩 스타일에 대한 조언을 할 때는 친근하고 편안하며 격려하는 어조로 말해야 합니다. 예를 들어, "무시하셔도 괜찮습니다." 또는 "혹시 코드를 변경하게 되면 그에 맞춰 수정하시면 됩니다."와 같은 표현이 좋습니다.

누구도 여러분의 리뷰 의견을 반드시 고려해야 할 의무는 없다는 점을 기억해 주세요. 만약 작성자가 여러분의 의견이 수정 범위 밖이라고 판단하여 반영하지 않겠다고 답한다면, 그것은 전혀 문제가 되지 않습니다 (특히 여러분의 의견이 사소한 부분에 대한 것일 경우 더욱 그렇습니다).

개선하다

가능하다면 검토하는 PR의 난이도와 우선순위를 높이세요.

리뷰의 양보다 질이 훨씬 중요합니다. 우선순위가 높고 어려운 PR에 대해 심층적이고 질 높은 리뷰를 제공함으로써 더 많은 것을 배우고 더 큰 가치를 창출 할 수 있습니다. 이러한 PR은 담당자에게 부담감을 주고 몇 달 동안 방치될 수 있으며, 질 높은 리뷰 부족, 코드 스타일 관련 사소한 지적, 리베이스 관련 댓글 등으로 인해 열정이 식어버릴 수 있습니다. 이러한 PR을 제대로 리뷰하는 것은 비트코인에 진정한 도움이 됩니다.

개선 과정에는 시간이 걸립니다. 배경을 이해하고, 코드를 주의 깊게 살펴보고, 문제를 보고하고, PR을 제출하고, #bitcoin-core-dev IRC 채널과 bitcoin-dev 메일링 리스트에 참여하는 데 수년간 투자한 시간은 무엇으로도 대체할 수 없습니다.

리뷰를 시작하기 전에 "이 단계에서 가장 필요한 것은 무엇인가?"라는 질문을 던져보는 것이 유용합니다. 이 질문에 답하려면 경험과 축적된 배경 지식이 필요하지만, 최소한의 시간으로 최대한의 가치를 창출하는 방법을 파악하는 데 그 가치가 있습니다. 변경 사항의 복잡성과 중요도, 그리고 PR이 리뷰 프로세스에서 이미 거친 단계에 따라, 디버깅, 개발, 테스트, 모든 커밋 검토를 포함하는 전체 리뷰 대신, 핵심 위치에 관련 코드 주석을 달고 코드를 훑어보는 것으로 충분할 수도 있습니다. 하지만 대부분의 경우, 제대로 대량 포괄적인 리뷰를 수행하는 것이 가장 효과적이며 가장 큰 가치를 제공합니다.

한 단계씩 차근차근

자기 평가와 욕망은 배제하세요. 개인적인 감정에 휘둘리지 말고, 일을 앞으로 나아가게 하세요.

확신이 서지 않을 때는 상대방이 선의를 가지고 있다고 가정하십시오.

사람과 결과에 대해 인내심을 가지세요.

공개적인 칭찬과 사적인 비판은 모두 필요하지만, 비판에는 격려가 반드시 수반되어야 한다.

계속해서 도움을 제공하세요. 매일매일 노력하세요.

말처럼 쉬운 일은 없죠. 자신을 용서하고, 다른 사람들도 용서하세요.

다음 사항을 꼭 기억해 주세요: PR을 생성하기 전에 5~15개의 PR을 검토하거나 5~15개의 이슈 보고서를 처리/테스트해 보세요.

마지막으로, 동료나 지인뿐 아니라 다양한 배경과 경험 수준을 가진 사람들의 기여가 얼마나 가치 있는지 이해하십시오. 새로운 친구들에게 연락하고(IRC 메시지를 통해 직접 연락해도 좋습니다) 그들이 무엇을 필요로 하는지 물어보세요. 가끔 도움을 요청할 수는 있지만, 도움을 당연한 권리처럼 여기지 마십시오. 더 많이 주고 덜 받으십시오.

기술적 세부 사항

맹목적으로 믿지 말고 검증하세요. 코드 검토 과정에서 GitHub에 대한 의존도를 최소화하십시오. GitHub 웹사이트는 댓글 읽기 및 추가와 같은 메타데이터 확인 용도로만 사용하고, 커밋 및 코드 검토는 로컬 환경에서 수행해야 합니다.

로컬 머신용 코드 가져오기

따라서 검토 프로세스는 먼저 사용자의 컴퓨터로 PR 브랜치를 가져와 로컬에서 컴파일하고 검토하는 것으로 시작됩니다. 아이디어, 요구 사항, 디스크 공간 및 인터넷 대역폭에 따라 다양한 방법이 있습니다. 다음은 몇 가지 예입니다.

1. git checkout pr/<number> 사용하여 원격 저장소에서 PR을 가져올 수 있습니다. 이 간결한 gist 문서에서 설명하는 것처럼 필요에 따라 명령어를 수정할 수 있습니다.
2. 내 Git 설정의 [remote "origin"] 섹션: fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
3. Bitcoin Core 기여자 Luke Dashjr의 버전: "모든 병합 브랜치를 피하려면 origin-pull 원격 저장소를 다음과 같이 구성하십시오." fetch = +refs/pull/*/head:refs/remotes/origin-pull/*/head
4. Bitcoin Core 문서: refspec을 사용하여 PR을 쉽게 참조할 수 있습니다.
5. GitHub에서는 pull/<number>/head (기여자 브랜치)와 pull/<number>/merge (마스터 브랜치로 병합) 명령어를 사용하여 PR을 업스트림 코드베이스의 브랜치로 보여줍니다 . 예를 들어 git fetch origin pull/17283/head && git checkout FETCH_HEAD 같이 사용할 수 있습니다. 하지만 저는 GitHub를 가능한 한 적게 사용하는 편입니다.

PR은 기여자 브랜치 또는 변경 사항이 병합된 마스터 브랜치에서 테스트할 수 있습니다. 특히 마스터 브랜치에서 테스트하는 것은 마지막 PR 커밋 이후 마스터 브랜치에 병합된 내용으로 인해 변경 사항이 깨졌는지 확인하는 데 매우 유용합니다.

그러면 코드를 읽으면서 동시에 로컬에서 컴파일 및 테스트를 시작할 수 있습니다. 많은 PR을 테스트해야 하므로 소스 코드에서 비트코인 ​​코어를 능숙하게 컴파일하고 단위 및 기능 테스트를 실행할 수 있어야 합니다. 따라서 비트코인 ​​코어 생산성 가이드는 필수적입니다.

비트코인 코어 개발자 노트를 읽고 알아보세요.

비교 도구

컴파일 및 테스트가 진행되는 동안 gitk , meld , macOS용 meld , Emacs용 GNU ediff , Vim용 vimdiff 또는 vim-diffconflicts , macOS용 opendiff, diffoscope 와 같이 차이점을 강조 표시해주는 비교 도구를 사용하여 로컬 환경에서 각 코드 커밋을 검토하세요( 비교 도구 사용 가이드는 여기에서 확인할 수 있습니다).

gitk를 사용하고 다크 모드를 선호한다면 Dracula for gitk를 사용하는 것을 추천합니다.

Git Grep

git grep 능숙하게 사용하여 코드 저장소를 검색하세요. 저장소에서 필요한 내용을 찾을 때까지 계속 사용하게 될 것입니다. 도움이 필요하면 명령줄 환경에서 git grep --help 실행하세요.

어디서부터 시작해야 할지 모르겠다면

코드를 읽고, PR 댓글을 읽은 다음, 다시 돌아가서 둘 다 다시 읽으세요. 이해가 안 되는 부분을 찾아서 스스로 해결해 나가세요. 이 과정을 계속 반복하세요.

모든 것이 명확해지면 regtest/testnet에서 bitcoind 실행하거나 (소정의 수수료를 내고 메인넷에서도 실행 가능) 관련 로그를 추적하고 검색하세요. ( bitcoin-cli help logging 실행하면 bitcoind 다양한 로그 범주와 활성화/비활성화 방법을 확인할 수 있습니다.)

LogPrintf 나 assert 같은 사용자 지정 로깅 로직을 추가할 수 있습니다. 하지만 다른 사람이 작성한 코드에 이러한 로직을 추가하는 것은 권한이 필요합니다(이유를 이해하려면 코드베이스에서 git grep -ni logprintf 또는 git grep asset 실행해 보세요).

관련 기능 테스트를 실행하고 디버그 로그를 검토합니다. 마스터 브랜치에서 테스트가 실패하는 방식이 예상과 일치하는지 확인합니다. 그런 다음 PR 브랜치로 돌아가서 새 테스트를 되돌리거나 수정하여 실패하도록 만들고 그 이유를 파악합니다.

C++의 gdb 나 Python의 pdb를 사용하거나 (또는 ​​기능 테스트 코드에 import pdb:pdb.set_trace() `를 추가하면) 중단점을 확인할 수 있습니다. 평가해 보세요. RPC 명령을 실행해 보세요.

PR이 호출 사이트, 헤더 파일 또는 선언을 무시했는지 확인하십시오.

코드를 더 나은 상태로 리팩토링하고 작동하지 않는 이유를 찾아보세요. 예상보다 두 배는 더 오래 걸릴 수 있다는 점을 감안하세요. 네, 그게 바로 해야 할 일입니다.

strace( man page strace )를 실행하여 시스템 호출 및 신호를 추적할 수 있습니다.

변경 내용에 따라 벤치마크 결과, 메모리 분석/Valgrind 결과, 또는 오류 그래프를 PR 검토에 첨부하는 것이 매우 유용할 수 있으며, 심지어 결정적인 역할을 할 수도 있습니다.

기술 자료

저는 비트코인 ​​코어를 개발하면서 자주 참고하는 다양한 기술 노트를 모아놓은 문서를 작성했습니다. 해당 문서는 jonatack/bitcoin-development/notes.txt 에서 확인할 수 있습니다. 코드베이스 내에도 이러한 노트가 포함된 유용한 자료들이 있습니다. fanquake/core-review 또한 훌륭한 참고 자료입니다.

디버그

비트코인 코어 디버깅 방법을 설명하는 두 개의 훌륭한 요약 문서:

• 파비안 야르 의 " 비트코인 코어 디버깅 "
• " GDB 또는 LLDB를 사용한 비트코인 ​​코어 심층 분석 및 디버깅 ", 앤젤 레온 저

누락된 테스트를 추가합니다

코드를 리뷰하는 동안에도 직접 테스트를 작성하면 코드 작동 방식을 이해하고 변경 사항을 검증하는 데 도움이 됩니다. 또한, 테스트가 유용한 코드 커버리지를 제공한다면 작성자에게 해당 테스트를 PR에 포함하도록 제안할 수 있습니다. 자동화된 테스트를 제안하는 것은 기여를 시작하는 매우 효과적인 방법입니다. 작성자는 누군가가 코드를 리뷰하고 추가 테스트를 제공해 줄 때 매우 감사하게 생각할 것입니다. 다음은 예시입니다 .

파노라마에서 니트까지

전체적인 그림이 NIT, 맞춤법, 코드 스타일보다 훨씬 중요하다는 점을 기억해 주세요. 위의 "NIT" 부분을 다시 한번 읽어보시기 바랍니다. 리뷰 과정에서 다른 지적할 내용이 없더라도 이러한 사항에 대해서는 언급하지 않도록 노력해 주세요. 저도 여러 번 그런 유혹에 넘어간 적이 있어 어렵다는 것을 알고 있지만, 더 나은 대안들이 있습니다.

질문

리뷰어로서 (코드에 대한 전문 지식이 없더라도) 할 수 있는 가장 좋은 일 중 하나는 질문하는 것 입니다. PR 작성자는 일반적으로 자신의 작업에 대해 이야기하고 관심을 보이는 것을 좋아합니다. 따라서 20분 정도 시간을 내어 변경 사항을 살펴보고 가장 혼란스럽거나 예상치 못한 부분을 파악한 다음, PR 댓글(또는 #bitcoin-core-dev 채널)에 정중하게 질문하세요. 다른 사람들도 같은 문제로 혼란스러워할 수 있으며, 질문을 통해 해당 부분을 더 명확하게 설명하고 문서화할 수 있습니다. 이렇게 하면 여러분과 프로젝트 모두 새로운 것을 배우고 프로젝트를 더 이해하기 쉽게 만드는 데 도움을 줄 수 있습니다 (이 문단은 Russ Yanofsky 의 아이디어에서 가져왔습니다).

동료 평가

Bitcoin Core의동료 평가 프로세스를 숙지하고 이해했는지 확인하십시오. 이 프로세스는 자주 업데이트 되므로 정기적으로 검토하십시오.

" ACK "( 출처 )는 일반적으로 감사자가 변경 사항을 검토하고 수동으로 테스트한 방법을 설명한 후에 사용됩니다. 새로운 기여자의 경우, 변경 사항에 대한 이해도를 보여주기 위해 검토 의견에 수행한 작업과 생각에 대한 자세한 설명을 제공하는 것이 좋습니다.

"컨셉 ACK"는 리뷰어가 변경 목표에 동의하지만 코드 검토 또는 테스트를 수행했는지 여부는 아직 밝히지 않았다는 의미입니다. 이는 PR 작성자에게 PR이 가치 있고 올바른 방향으로 나아가고 있음을 알려주는 중요한 신호가 될 수 있습니다. 반대로 "컨셉 NACK"는 PR 목표에 동의하지 않음을 나타냅니다.

"접근 방식 동의(Approach ACK)"는 개념적 동의(Conceptual ACK)보다 한 단계 더 나아가, PR의 목표와 그 목표를 달성하기 위한 방법 모두에 동의한다는 의미입니다. 반면 "동의하지 않음(NACK)"은 목표에는 동의하지만 목표 달성 방법에는 동의하지 않는다는 것을 나타냅니다.

코드 리뷰어는 코드가 괜찮아 보이지만 변경 사항을 테스트하지 않았거나 개념에 대한 관점 형성하지 않았음을 나타내기 위해 "코드 리뷰 완료(ACK)"라는 댓글을 남기는 경우가 있습니다. 이때 "코드 리뷰 완료(ACK HEAD , 개념의 목적이 아직 명확하지 않습니다. x, y, z 등을 검증하겠습니다."와 같이 더 자세한 맥락을 추가하는 것이 좋습니다.

다른 ACK 변형으로는 ACK가 테스트되었음을 ​​나타내는 "tACK" 또는 "tested ACK"와 ACK가 테스트되지 않았음을 나타내는 "utACK" 또는 "untested ACK"가 있습니다.

새로운 기능을 직접 테스트하거나 문제를 보고하는 것은 언제든 환영합니다. "테스트 결과와 방법은 다음과 같습니다."와 같은 설명을 덧붙여 주시면 매우 유용하며, 특히 마지막에 "ACK"를 남겨주시면 더욱 좋습니다.

일부 풀 리퀘스트는 복잡성, 맥락 또는 테스트 및 모킹 프레임 의 부재로 인해 테스트하거나 승인하기 어려울 수 있습니다. 예를 들어, 코드를 꼼꼼히 검토하고 "코드는 맞는 것 같지만, 작동 방식에 대해 확신이 서지 않아 승인(ACK)을 드리기 어렵습니다."와 같은 의견을 남기는 것 또한 매우 가치 있는 기여입니다.

그 외에도 "move-only"가 포함된 댓글에 대해 "move-only 부분을 확인했습니다"와 같은 유용한 댓글과, "X를 변경하면 Y가 고장날 수 있는지 알아내려고 애썼지만 아무런 결과도 얻지 못했습니다(정말 이런 일이 일어날까요?)"와 같은 댓글이 있습니다.

제출 해시를 포함한 ACK

ACK를 보낼 때는 검토 중인 코드의 상태를 나타내기 위해 HEAD 커밋(또는 검토 중인 커밋)의 해시값을 추가하세요. 신뢰할 수 없는 환경에서 올바른 방법은 GitHub 웹페이지의 해시값이 아닌 로컬 브랜치의 해시값을 사용하는 것입니다. 이렇게 하면 로컬 도구가 손상되지 않는 한 특정 변경 사항에 대한 ACK를 보낼 수 있습니다. 또한 강제 푸시로 인해 연결된 이전 커밋이 GitHub에서 사라진 경우에도 유용합니다.

완전한 승인(ACK)은 다음과 같아야 합니다. " fa2f991 승인합니다. 컴파일, 테스트 실행, X/Y/Z 실행을 통한 수동 테스트, 코드 검토를 완료했습니다. 코드가 양호해 보이며 병합해도 괜찮다고 생각합니다."

현재 비트코인 ​​코어 병합 스크립트는 병합 시점의 HEAD 커밋과 관련된 모든 ACK 주석의 첫 번째 단락을 병합된 커밋에 복사합니다. 따라서 ACK 주석에 작성하는 모든 내용은 병합 스크립트에 의해 복사되어 Git 기록에 영구적으로 저장된다는 점을 기억하세요.

복잡하거나 리스크 가 높은 홍보 활동의 경우, 합병 전에 최소 3~4명의 경험 많은 투자자가 필요할 수 있습니다.

아파치 투표 시스템

Bitcoin Core 운영진은 댓글에서 아파치 투표 시스템을 자주 사용합니다. 다음은 그 예시 입니다.

타인에 대해 좀 더 관대해지세요

코드 자체를 검토하세요. 코드 작성자나 그들의 댓글을 검토하지 마세요.

의견이 다를 때는 자신의 관점 명확하게 밝히고 다음으로 넘어가세요. 예를 들어 , 여러 개의 게시글로 댓글을 도배하거나, 위협하거나 과잉 반응하지 마세요. 인내심을 갖고 공격적이거나 괴롭히는 행동은 삼가세요. 가장 중요한 것은 논의 중인 주제 자체가 아니라 다른 참여자들과의 관계라는 점을 기억하세요.

새로운 기여자분들은 NACK를 줄 때 주의하세요. NACK는 맥락에 대한 이해 부족을 전제로 합니다. 꼭 NACK를 줘야 한다면, 타당한 이유를 제시해 주세요. 다음은 예시입니다 .

OpenTimeStamp 서명을 사용하여 제출하세요.

일부 비트코인 ​​기여자들은 ACK에 서명하고 OpenTimeStamp(오픈 타임스탬프)를 첨부합니다. 이는 이 글의 범위를 벗어나지만, Git 플러그인을 사용하여 OpenTimeStamp로 커밋에 서명하는 것은 매우 간단합니다.

접을 수 있는 댓글

조금 지나면, 기여자분들 이 댓글 관리를 위해 접을 수 있는 기능을 사용하는 것을 보실 수 있을 겁니다. 멋지네요 ! 어떻게 하는 걸까요 ? HTML의 ` details 태그를 사용합니다. 여기 사용 설명서가 있습니다 .

감사의 말씀

이 글을 검토하고 제안을 해주신 스티브 리 (머니볼)와 마이클 폴크슨 에게 감사드립니다.

이 글에서는 우리가 감사해야 할 비트코인 ​​코어 개발자들을 조명하며, GitHub와 IRC에서 확인한 댓글들을 포함시켰습니다. 해당 개발자는 Wladimir van der Laan, Marco Falke, Pieter Wuille, Gregory Maxwell, Anthony Towns, 그리고 Russ Yanofsky입니다.

수년간 저는 비트코인(BDFL, 종신 자비로운 독재자)이 프로그래밍 언어와 오픈 소스 프로젝트에 미치는 영향에 환멸을 느꼈습니다. 하지만 블라디미르 반 데르 라안이 비트코인에 보여준 오랜 기간 동안 의 겸손한 봉사는 제가 오픈 소스 프로젝트에 다시 관심을 갖게 하는 계기가 되었습니다.

마지막으로, 제 제출물을 검토하는 데 인내심을 보여주신 모든 비트코인 ​​코어 기여자분들, 특히 John Newbery, Marco Falke, João Barbosa, practicalswift, Gregory Sanders, Jonas Schnelli, Pieter Wuille, 그리고 Wladimir van der Laan께 진심으로 감사드립니다. 또한 초기 단계에서 조언과 제안을 해주신 Adam Jonas와 John Newbery께도 감사드립니다.

(위에)