4.1. 게시판 선택하기

어디에 질문을 할지 선택할 때 신중하라. 다음과 같은 경우 무시되거나 멍청이로 취급받을 수 있다.

1. 게시판의 주제에 벗어나는 질문을 올릴 때

2. 고급 기술 질문을 다루는 곳에서 기초적인 질문을 할 때, 혹은 반대되는 경우

3. 너무 많은 뉴스그룹에 동시투고 할 때

4. 당신을 알고 있지 못하고 문제를 해결해야 할 의무도 없는 사람에게 이메일을 보냈을 때

해커들은 공동체의 대화수단이 엉뚱한 글들로 가득채워지는 것을 방지하기 위해 당신의 글을 날려버릴 수 도 있다. 당신에게 이러한 일이 일어나기를 바라지는 않을 것이다.

그래서 첫 번째 단계는 적당한 게시판을 찾는 것이다. 역시 Google과 다른 웹서치엔진들이 도움이 될 수 있다. 문제와 관련된 하드웨어 또는 소프트웨어의 프로젝트 홈페이지를 찾는데 검색엔진을 이용하십시오. 보통 프로젝트 홈페이지는 FAQ(자주 묻는 질문과 답), 메일링리스트를 를 가지고 있습니다. 이 것들이 당신의 노력이 답을 찾지 못한다면 마지막으로 도움을 요청해야 할 곳 입니다.

당신이 익숙하지 않은 게시판이나 사람에게 질문을 하는 것은 위험합니다. 좋은 정보가 있는 사이트의 주인이 당신에게 꽁짜로 컨설팅을 해줄 것이라고 기대하지 마십시오. 당신의 질문이 환영받을 것이라고 어떤 긍적적인 가정도 하지 마십시오. 확실하지 않다면 다른 곳으로 보내거나 질문을 보내는 것을 그만두십시오.

뉴스그룹이나 메일링리스트를 선택할 때, 이름만 보고 그 내용을 판단하지 마십시오. FAQ를 보고 당신의 질문이 그곳의 주제와 관련된 것인지 확인해 보십시오. 먼저 이미 그 곳에 포스팅되어 있는 글을 읽어 보면 일이 어떻게 진행되고 있는지 감을 잡을 수 있을 겁니다. 이렇게 해서 답을 찾을 수 도 있습니다. 혹은 좀 더 나은 질문을 만들 수 있습니다.

당신의 주제가 뭔지 알고있어야 합니다. 전형적인 실수는 Unix, Window양쪽에서 돌아가는 라이브러리, 언어, 툴을 다루는 곳에서 Unix, Window 프로그래밍 인터페이스에 관해 묻는 것입니다. 이것이 왜 실수인지 알 수 없다면 알기전까지 어떤 질문도 하지 않는 것이 좋을 것 같습니다.

대개 잘 선택된, 그리고 공개된 곳에 하는 질문이 비공개 된 곳에 하는 질문보다 대답받을 확률이 높습니다. 여러가지 이유가 있을 수 있습니다. 하나는 답변할 수 있는 사람의 숫자가 더 많다는 것 이고. 다른 하나는 그 청중의 수가 많다라는 것입니다. 해커는 몇 명만 알 수 있는 것 보다 한 꺼번에 여러명을 가르칠 수 있는 곳에 답변하고 싶을 겁니다.

이해할 수 있겠지만, 실력있는 해커나 유명한 소프트웨어의 저작자 들은 이미 그들이 처리할 수 있는 범위 밖의, 잘 못 보내진 메일을 받고 있습니다. 이 메일 홍수 속에서 당신은 이미 낙타의 등을 부러트릴 지푸라기 한 올이 될 수도 있습니다. 벌써 몇 번이나, 유명한 프로젝트의 공헌자들이 쓸모없는 이메일들로 인해 개인적인 메일계정이 피해를 입어 사용자 지원을 중지한 경우가 있습니다.

4.2. 가능하다면 프로젝트 메일링리스트를 이용해라

프로젝트가 개발 메일링리스트를 가지고 있다면 메일링리스트에 질문을 올리십시오. 누가 가장 잘 답변해 줄 지 알때라도, 개인개발자에게 메일을 직접 보내지 마십시오. 메일링리스트 주소를 프로젝트의 참조문서나 홈페이지에서 확인해서 이용하십시오. 여기에는 몇 가지 이유가 있습니다.

• 답변받을 만큼 좋은 질문은 전체그룹에 공유될 가치가 있습니다. 반대로 질문이 너무 바보같다면 개인개발자를 성가시게 한 것은 용서받을 수 없습니다.

• 메일링리스트에 질문하는 것은 개발자들간의 일을 나누어 줍니다. 개인개발자 특히 리더는 질문에 답하기에는 너무 바쁠 수 있습니다.

• 대부분의 메일링리스트는 아카이브에 저장되고 아카이브는 서치엔진에 의해 인덱스됩니다. 나중에 다른 사람이, 리스트에 같은 질문을 올리는 것 대신에, 당신의 질문을 찾고 답을 볼 수 있을 지도 모릅니다.

• 어떤 질문이 자주 리스트에 보인다면, 개발자는 그 정보를 문서를 고치거나 소프트웨어를 좀 덜 헷갈리도록 고치는 데 사용할 수 있습니다. 그러나 개인적으로 질문이 된다면 아무도 어떤 질문이 자주 되는지 모를 것 입니다.

만약에 프로젝트 메일링리스트를 확인해 볼 수 없고 프로젝트관리자의 메일 주소만 보인다면 그 쪽으로 메일을 보내십시오. 그러나 이 경우에도 메일링리스트가 없을 거라고 가정하지 마십시오. 메일에 메일링리스트를 찾으려고 했지만 실패했다고 적으십시오. 그리고 다른 사람에게 메세지가 포워드되어도 괜찮다고 언급하십시오. (많은 사람들이, 메일 안에 비밀이 없더라도, 개인적인 e-mail은 개인적으로 남아야 한다고 믿습니다. 당신의 메일이 포워드가능하도록 허락해서 메일을 받는 사람이 메일처리방법을 선택하도록 할 수 있습니다.)

4.3. 답변하기 쉽게 질문하기

질문을 "xxx@xxx.com으로 답변해주세요"라고 끝내는 것은 오히려 더 답변을 얻기 힘들게 합니다. 메일프로그램에서 Reply-To 헤더를 설정하는 데 몇 초를 쓸 수 없다면, 우리도 문제를 생각하는데 몇 초라도 쓸 수 없습니다. 메일프로그램이 Reply-To 헤더 설정을 지원하지 않는다면 메일프로그램을 바꾸십시오. OS가 이 기능을 사용할 수 있는 어떤 프로그램도 지원하지 않는다면 OS를 바꾸십시오.

4.4. 명확하고, 문법적으로 올바른 질문하기

우리는 경험으로 주의가 부족한 조잡한 문장을 쓰는 사람들이 생각과 코딩도 마찬가지라는 것을 알고있다. (내기를 걸어도 될 많큼 충분히 많다.) 주의부족인 조잡한 생각을 하는 사람들을 위해 답변하는 것은 쓸 모 없는 짓이다. 차라리 다른 곳에 시간을 사용할 것 이다.

그래서 질문을 표현할 때는 명확히 하는 것이 중요하다. 그렇게 하는데 신경을 쓸 수 없다면 우리도 신경쓸 수 없다. 당신의 언어를 갈고 닦는데 노력해라. 질문이 형식을 차릴 필요는 없다. 사실 해커들은 비형식적이고, 자유롭고 유머있는 언어가 정확하게 쓰여진 것을 좋아한다. 다만 질문에 당신이 생각하고 신경썼다는 것을 알릴만한 표시가 있어야 한다.

문법적으로 올바로 적어라. "its"를 "it's"와, "loose"를 "lose"와 "discrete"를 "discreet"와 헷갈리지 말아라. 모든 글자를 대문자로 적지 말아라. 이 것은 소리지르는 것처럼 보이고 무례한 것으로 받아 들여 진다. (모든 글자가 소문자인 것은 좀 덜 화나지만 읽기가 힘들다. Alan Cox는 그 럴 수 있지만, 당신은 그렇지 않다.)

만약 적당히 교육된 얼간이 처럼 쓴다면 대부분 무시당할 것이다. 'l33t script kiddie haxOr'과 같이 쓰는 것은 죽음에의 키스이고 당신이 무거운 침묵이외에는 받을 것이 아무것도 없다는 것을 보장한다. (또는 경멸과 비꼼이 가득찬 도움을 받을 것이다.)

모국언어가 쓰이지 않는 곳에서 질문을 하다면, 아마도 약간의 철자와 문법에러는 용서 받을 것이다. 그리나 게으름 때문에 생긴 잘못은 용서할 수 없다.(그렇다. 우리는 차이점을 알 수 있다.) 그리고 상대방이 어떤 언어를 사용할지 알 수 없다면 영어를 사용하라. 바쁜 해커들은 알 수 없는 언어로 쓰여진 질문들은 무시하는 경향이 있다. 그리고 영어는 인터넷에서 주로 사용하는 언어이다. 영어를 사용함으로써 질문이 읽어지지 않는 경우를 최소화할 수 있다.

4.5. 이해하기 쉬운 형식으로 질문하기

질문이 읽기가 힘들다면, 다음 중에 하나를 만족하고 있지 않은지 확인해 보라.

• HTML이 아니라 Text형식으로 보내

• MIME 파일첨부는 보통 괜찮다. 메일프로그램에 의해 자동생성된 것이 아니라 내용이 있는 것(source파일, patch)이라면...

• 전체 단락이 한 줄로 되어 있는 메일을 보내지 말라. (메세지의 일부분을 읽기 힘들게 만든다.) 상대방이 80컴럼을 가지고 있다고 가정하고 80보다 작은 값으로 line wrap을 설정하라.

• 그러나 로그파일 덤프나 session스크립트 같은 data 는 고정된 컬럼크기로 wrap하지 마라. data는 그대로 포함되어야 한다. 상대방이 당신이 본 것과 똑 같은 것을 보고 있다고 믿을 수 있어야 한다.

• MIME Queoted-Printable 인코딩으로 된 메일은 영어를 쓰는 곳으로 보내지 마라. 이 인코딩은 ASCII코드가 표현할 수 없는 언어를 쓰는 곳에서만 필요가 있다. 그러나 많은 메일프로그램이 이 인코딩을 지원하지 않아서, '=20'과 같은 글자가 글자안에 보기 싫게 흩어져 보일 수 있다.

• 절대로 해커가 Miscrosoft 워드같은 비공개된 파일 포맷을 읽을 수 있을 거라고 생각하지 말라.

• 윈도우에서 메일을 보내고 있다면, Microsoft의 "Smart Quotes" 기능을 꺼라. 이 기능을 끄면 메일안에서 번쩍이는 쓰레기 글자를 보지 않아도 된다.

만약에 GUI 메일 클라이언트를 이용하고 있다면 (MS Outlook, Netscape Messenger, etc) 이 프로그램들을 디폴트 설정으로 이용하는 것은 위의 룰들을 깰 수 있다는 것을 명심하라. 대 부분, 이런 메일 클라이언트들은 "View Source" 메뉴를 가지고 있다. 이 메뉴를 "보낸 메일"폴더에서 사용해 보고 불필요한 찌꺼기가 첨부로 붙지 않고 plain text인 메일을 보내고 있는지 확인해라.

4.6. 의미있고 분명한 제목을 사용하라.

제목은, 메일링리스트나 뉴스그룹에서, 50개 정도의 글자로 검증받은 숙련된 전문가들의 관심을 끌 수 있는 황금같은 기회이다. "제발 도와주세요"와 같은 쓸모없는 말을 쓰지 말아라. ("제발 도와주세요" 같은 제목을 보면 무시해버리세요. 이런 제목을 가진 글은 반사적으로 무시될 겁니다.) 당신의 얼마나 급한 사정인지로 우리를 감동시키려고 하지 마십시오. 공간을 당신의 문제를 설명하는데 사용하십시오.

많은 사용자지원 기관에서 사용되는, 제목작성에 사용되는 관례는 '주제 - 이상한 점' 입니다. '주제' 부분에는 문제를 격고 있는 것을 적고 '이상한 점'에는 예상했던 것과 다른 행동을 보이는 것을 적습니다.

바보: 도와주세요. 제 노트북에서 비디오가 나오질 않아요!

똑똑함: XFree86 4.1 misshapen mouse cusor, Fooware MV1005 vid. chipset

더 똑똑함: XFree86 4.1 mouse cursor on Fooware MV1005 vid. chipset - is misshapen

"주제 - 이상한점"으로 설명을 적으면 생각을 좀 더 다듬는데 도움이 될 겁니다. 뭐가 이상하냐고요? 마우스 커서 뿐인가요, 아니면 다른 그래픽도 그런가요? XFree86만 이상한가요? 버전 4.1에서만 이상한가요? Fooware 비디오 칩셋에서만 그런가요? 모델 MV1005에서만? 이 제목을 보는 사람은 한 눈에 당신이 어떤 것과 문제를 겪고 있는지 어떤 문제를 겪고 있는지 알 수 있을 겁니다.

답변하기 버튼을 눌러 질문을 하고 있다면 질문하고 있다는 것을 나타내도록 제목을 바꿔라. 다음과 같은 제목, "Re : test" 또는 "Re: new bug"는 충분한 주의를 끌지 못 할 것이다. 그리고 새로 이 글을 읽는 사람들이 단서를 얻을 수 있는 최소한의 부분을 제외하고 이전 메세지를 인용한 부분을 잘라내십시오.

4.7. 명확하지만 자세하게 질문하라

• 문제나 버그의 증상을 주의깊게 명확하게 설명하라.

• 문제가 일어난 환경을 설명하라.(machine, OS, application, whatever)

• 질문하기 전에 문제를 해결하거나 이해하기 위해 해보았던 것를 설명하라.

• 질문하기 전에 문제의 범위를 줄이기 위해 시도해 본, 진단에 도움이 되는 절차를 설명해라.

• 관련이 있을 만한, 컴퓨터나 소프트웨어에 최근에 일어난 변화를 설명하라.

당신이 도움을 요청할 때 해커가 할 만한 질문을 예상하고, 거기에 미리 답해 놓기 위해 최선을 다하라.

Simon Tatham은 효율적으로 버그 리포트하는 방법이라는 훌륭한 에세이를 썼다. 한 번 읽어 볼 것을 추천한다.

4.8. 양이 많다고 명확한 것은 아니다

질문은 명확하지만 자세해야 한다. 이것은 한 무더기의 code와 data를 적는다고 해서 되는 것이 아니다. 만약에 버그를 일으키는 크고 복잡한 테스트 케이스를 가지고 있다면 될 수 있는대로 잘라내고 최대한 작게 만들어야 한다.

이 것은 적어도 세가지 점에서 유용하다. 첫 째, 질문을 단순화 시키려고 노력함으로써 답변받을 가능성을 높일 수 있다. 둘 째, 질문을 단순화 시키는 것은 유용한 답변을 얻을 가능성을 높인다. 셋 째, 버그 리포트를 만들려고 노력하면서 fix를 개발하거나 workaround를 만들 수 있다.

4.9. 추측이 아니라 증상을 설명하라.

뭐가 문제를 일으키는 것 같다는 추측을 해커에게 말하는 것은 도움이 되지 않는다. (당신의 진단이론이 그렇게 훌륭하다면 왜 다른 사람에게 도움을 바라나요.) 당신의 판단이나 이론을 말하는 것이 아니라 뭐가 잘못되었지 가공되지 않은 증상을 말하도록 해라. 해커가 판단하고 해결하게 하라.

바보 : 커널 컴파일 도중에 SIG11 에러가 때때로 일어 나고 있습니다. 마더보드에 미세한 균열이 일어난 것이 아닐까 싶습니다. 이 문제인지 체크하려면 뭐가 가장 좋은 방법일까요?

똑똑함: 집에서 조립한 FIC-PA2007마더보드(VIA Apollo VP2 chipset) K6/233에 장착된 Corsair PC133 SDRAM이, 파워를 켠 후 20분쯤 후 커널 컴파일 도중에 SIG11에러가 발생하고 있습니다. 첫 20분간은 에러가 발생하지 않습니다. 리부팅을 하면 시계가 다시 시작하지 않고, 밤 새도록 전원을 꺼둔다음 리부팅하면 그렇습니다. 모든 RAM을 바꿔 보았지만 소용없고요. 컴파일 세션에서 관련된 부분은 다음과 같습니다.

4.10. 문제의 증상을 시간 순서대로 설명하라

뭐가 잘 못되 었는지 알아내는데 쓰이는 가장 유용한 단서는 문제가 일어나기 바로 전에 일어난 사건에 있는 경우가 많다. 그래서 문제의 설명은 정확히 "당신이 무엇을 했고, 컴퓨터가 무엇을 해서 문제가 일어났다"라고 적어야 한다. 커맨드라인 명령의 경우 session log를 남겨서 관련이 있는 20줄 정도를 인용하는 것은 매우 유용하다.

만약에 프로그램이 -v 같은 진단 옵션을 가지고 있다면, 어떤 옵션이 디버깅에 유용한 정보를 줄 지 잘 판단해서 실행해 본다.

만약이 이야기가 길다면 (4단락 보다 길다면) 문제를 제일 위에 적고 , 그 아래에 시간순서대로 적는 것이 도움이 된다. 이렇게 하면 해커가 이야기를 읽으면서 뭘 주의해야하는지 알 것이다.

4.11. 개인메일로 답장을 달라고 요구하지 않기

해커들은 문제 해결이 공개적이고 투명한 과정 - 불완전하거나 잘못된 첫 번째 해결책을 보다 더 잘 아는 사람이 수정할 수 있고 그래야 하는 -을 통해 이루어 지기를 바란다. 그리고 그들의 동료들에게 능력있는 사람이라고 인정받는 것으로 보상받기를 원한다.

개인메일로 답장을 받기를 원하는 것은, 공개된 과정과 보상 둘 다를 방해하는 것이다. 개인메일로 답장을 요구하지 말라. 개인적으로 답장메일을 보내는 것은 상대의 선택일 뿐이다. 만약에 상대방이 답장을 준다면 보통 질문이 너무 형식에 맞지 않거나 다른 사람들에게도 분명히 흥미있을 거라고 생각해서 일 것이다.

여기에 한 가지 예외가 있을 수 있다. 질문이 너무 비슷한 종류의 해결책을 많이 받을 것 같다고 생각되는 경우, "저에게 메일을 보내시면 정리해서 뉴스그룹에 올리겠습니다"라고 적어서 보내라. 뉴스그룹과 메일링리스트를 내용상으로 같은 질문으로 채워지는 것을 막으려는 노력이다. 그러나 정리하겠다는 약속을 지켜야한다.

4.12. 문제에 대해서 명확하게 말하기

한계가 없는 질문은 시간을 소비하게만 하는 것으로 보일수 있다. 가장 훌륭한 답을 줄 수 있는 사람은 아마 가장 바쁜 사람들 중의 한 명일 것이다. (스스로 생계를 꾸려가고 있는 사람들을 겁니다.) 그런 사람들은 시간만 많이 소모하게 하는 명확하지 않은 질문을 싫어한다.

당신이 뭘 원하는지 명확할 수록 유용한 답을 얻을 수 있을 것이다. (코드를 보내고, 프로그램의 버전을 확인하고, 뭐든지..) 이렇게 하는 것은 답변하는 사람이 노력을 집중하게 하고, 그 들이 들여야할 시간과 에너지의 최대치를 암묵적으로 제한해 줍니다. 좋은 일입니다.

전문가들의 세계를 이해하려면, 전문가들은 풍부하지만 그들의 시간은 희소한 자원으로 생각해 보십시오. 당신이 더 적은 시간을 암묵적으로 요구할 수 록 정말 훌륭하고 바쁜 사람들로 부터 답변얻을 가능성이 높습니다.

그래서 전문가가 처리하기 위해 들일 시간을 최소화하기 위해 질문에 가장자리를 치는 것은 유용합니다. 질문에 가장자리를 치는 것은 질문을 단순화하는 것과는 틀립니다. 예를 들어 "X윈도우에 관한 문서가 있는 곳을 알려주시겠습니까?"라는 것은 "X윈도우에 관해 알려주세요, 제발"이라는 질문보다 똑똑한 질문입니다. 만약에 동작하지 않는 코드를 가지고 있다면, 다른 사람들에게 고쳐달라고 하는 것 보다 뭐가 잘못된 건지 알려달라는 것이 보다 나은 방법입니다.

4.13. 학교숙제 질문하지 않기

해커들은 어떤 질문이 학교숙제인지 쉽게 알 수 있습니다. 대부분 그 들도 숙제를 했었기 때문입니다. 이 숙제들은 당신이 직접 해서 경험을 얻을 수 있도록 하기 위한 것입니다. 힌트를 달라고 하는 것은 괜찮지만 전체 소스를 요구해서는 안됩니다.

4.14. 의미 없는 말 빼기

질문을, 문법적으로 아무 의미없는 말 예를들어 "도와주실 수 있을까요", "여기 답이 있습니까" 와 같은 말로 끝내고 싶은 유혹에 넘어가지 마십시오. 첫 째, 당신이 질문을 잘 적었더라도 이런 쓸모없는 말은 넘칠 뿐입니다. 둘 째, 해커들은 이런 문장에 화를 내며 논리적으로 아무 문제없지만 경멸하는 말투의 답 "네, 당신은 도움 받을 수 있습니다."나 "아니요, 당신을 위해 도움을 줄 사람은 아무도 없습니다."와 같이 쓸 수 있습니다.

4.15. "긴급" 이라고 적지 마세요

이건 당신 문제 입니다. 우리 문제가 아닙니다. 급하다고 주장하는 것은 매우 비생산적입니다. 대부분의 해커가 그런 메세지를 무례하고 빠른 응답을 얻기위한 이기적인 시도로 여기고 그냥 지워버릴 겁니다.

4.16. 예의바르게 질문하기

예의바르게 질문하십시오. "부탁드립니다."나 "미리 감사드립니다."와 같은 말을 사용하십시오. 당신을 무료로 도와주는 사람들의 시간에 대해 감사하고 있다는 것을 표현하십시오.

솔직히 말하면 이 건 문법적으로 정확하고 명확한, 질문을 하는 것보다 중요하지 않습니다.(대체할 수도 없습니다.) 해커들은 대부분 좀 무뚝뚝하지만 기술적으로 날카로운 버그 리포트를 예의바른 애매함보다 좋아 합니다. (이게 이해가 잘 안된다면 우리가 뭔가 가르쳐 줄 질문을 보다 중요하게 생각한다는 것을 기억하십시오.)

그러나 당신이 여러가지 질문을 가지고 있다면 예의바른 것이 당신이 답변받을 확률을 높여줄 겁니다.

4.17. 답변에 간단한 노트를 붙이싶시오.

해결된 후에 도움을 준 사람들에게 노트를 보내십시오. 어떻게 해결되었고 그들에게 다시 한번 감사한다고 말하십시오. 만약에 문제가 메일링리스트나 뉴스그룹의 일반적인 관심을 끌만한 것이면 거기에 Followup을 올리십시오.

가장좋은 방법은, 원래의 질문이 있는 글타레에 'FIXED'나 'RESOLVED'라는 제목을 붙여서 올리는 것입니다. 빠르게 돌아가는 메일링리스트에서 사람들이 "Problem X - FIXED"라고 붙은 글을 보면 원래 질문을 읽어 보는 시간 조차도 아낄 수 있습니다. 그리고 그 시간을 다른 질문들을 해결하는데 쓸 수 있을 겁니다.

Followup이 길거나 자세할 필요는 없습니다. 간단히 "안녕하세요. 네트워크 케이블이 문제였습니다. 모두 감사드립니다. Bill로부터 "라고 적는 것이 아무 것도 없는 것 보다 좋습니다. 사실 짧고 같단한 요약이 기술적인 깊이가 없는 것이라면 논문보다 낳습니다. 문제를 해결한 행동을 적으십시오. 문제해결과정을 모두 적을 필요는 없습니다.

좀 깊이가 있는 문제였다면 문제해결 과정을 요약한 것을 올려두는 것이 좋습니다. 마지막으로 문제를 설명하고, 뭐가 해결책이었는지 적으십시오. 그리고 실수할 만한 것들을 적으십시오. 도움을 준사람들의 이름을 적으십시오. 이런 식으로 친구를 만들어 갈 수 있습니다.

당신이 해결한 방법을 정확히 알려주는 것이 예의바른 행동이고 정보를 널리 알리는 행동이자 다른사람이 메일링리스트를 찾거나 뉴스그룹을 검색하는 것을 도와줄 수 있습니다.

마지막으로 이런 Followup은 도와준 모든 사람들이 완결되었다는 느낌을 얻도록 도와줍니다. 당신이 개발자거나 해커가 아니라면 이런 느낌이 당신에게 도움을 준 guru나 전문가에게 매우 중요하다는 것을 믿어 주십시오. 해결되지 않는 공허함은 당황스런 것입니다. 해커들은 해결되는 것을 매우 보고 싶어 합니다. 이런 가려운 곳을 긁어 주는 것은 좋은 업을 쌓는 것이고 다음 번에 질문을 올렸을 때 매우 도움이 될 겁니다.

다른 사람이 똑같은 문제를 겪는 것을 어떻게 방지할지 생각해 보십시오. 스스로 문서나 FAQ에 패치를 하는 것이 도움이 될지 물어 보십시오. 답이 예라면 메인테이너에게 patch를 보내십시오.

해커들이게 이런 행동은 관례적인 예의바름보다 보다 더 중요합니다. 이렇게 함으로써 다른 사람과 잘 지낼 수 있다는, 매우 중요한 자산인 평판을 얻을 수 있습니다.