친숙해 지도록“오픈 소스이고 패치를 제출하십시오”라고 어떻게 말합니까?

의 답변에 에 정식 레토르트 무엇 "그것의 오픈 소스 패치를 제출?" 많은 사람들이 단순히 사람들에게 패치를 요청하는 것은 거만하고 무례하다는 의견을 표명했습니다.

그러나 오픈 소스 프로젝트의 개발자는 메일 링리스트에 구현할 수있는 것보다 더 많은 기능 요청을 보게 될 것 같습니다. 따라서 사용자가 "기능 X를보고 싶다"고 말하면 문제의 진실은 일반적으로 패치를 제출하지 않으면 구현 가능성이 매우 적다는 것입니다. 또한 때때로 사용자를 컨트 리뷰 터로 전환하는 데 필요한 약간의 격려가 필요할 수도 있습니다.

반면에, 무례한 행동으로 인해 기여자들을 겁 내고 싶지는 않습니다.

그렇다면 "기능을 요구하는 대신 패치를 제출하십시오"라는 말을 어떻게하면 좋을까요?

업데이트 : 모든 제안에 감사드립니다! 나는 그들 대부분이 꽤 긴 설명이 필요하다는 것을 알았습니다. 그러나 (a) 격일로 같은 내용을 설명하거나 (시간이 너무 오래 걸림) (b) 이메일에 붙여 넣은 스 니펫을 사용하여 (비공식적으로 빨리 가져옵니다) 피하십시오. 내가 링크 할 수있는 문서에 이것을 작성한 사람이 있습니까?

(테스트 작성, 코드 컴파일 및 패치 제출 방법과 같은 프로젝트 관련 사항은 물론 문서화해야하지만 기술적 인 문제는 CONTRIBUTING.txt로 이동해야한다고 생각합니다.)

당신은하지 않습니다.

내가 경험 한 한 후보 기고자는 어설프게 기능 요청을 요청하여 기능 요청을 제출하지 않습니다. 그들은 일반적으로 이미 일정 수준의 참여를 요구합니다.

• [...]면 달콤하지 않습니까? A, B 및 C를 수행하는 것이 가능할 수 있습니다. (미끼가 있습니다. 시간이 없지만 여기에 당신이 할 수있는 아이디어가 있습니다.)
• 여기에 할 패치가 있습니다. [...]에 대한 수정 사항이 있습니다.
• [...] 할 패치를 작성하려고 생각하고 피드백을 사용할 수 있습니다.
• 기타.

기능 요청을 똑바로 제출하는 코더는 대개 이유가 있습니다. 그들 중 일부는 다음과 같습니다 (예를 들어 마지막 두 단어가 WordPress에서 발생한다는 사실을 알고 있습니다).

• 그들은 다른 오픈 소스 프로젝트에 깊이 빠져 있습니다. 즉 시간이 없습니다.
• 그들은 자유 라이더이며 물건을 그렇게 유지하려고합니다.
• 기술 수준을 넘어서거나 모르는 언어로 작성되었습니다.
• 그들은 더 나은 옵션이 없기 때문에 소프트웨어를 사용하며 냄새 나는 batsh * t ^ \ b 코드 더미를 다루고 싶지 않습니다.
• 이전 패치가 무시 / 거부 되었기 때문에 더 이상 귀찮게 할 수 없습니다. 즉, 시간을 낭비한다고 생각합니다.

더 일반적으로, 기능 요청은 원하는 경우에도 패치를 제공 할 수없는 최종 사용자로부터 제공됩니다. 특히 발권 시스템 외부에서 제출할 때.

가장 중요한 우선 순위는 잠재적 / 기존 기여자를 끄는 것이 아니라 새로운 것을 적극적으로 모집하는 것입니다. 그것은 매우 중요하며 나는 경험에서 이것을 말합니다. 새로운 코드베이스를 선택하는 이상한 방법이 있습니다.이 코드는 코드를 이해하고 일정 수준의 이해를 얻고 티켓팅 시스템에 뛰어 들며 쉽게 찾을 수있는 버그를 수정하여 내부를 깊이있게 이해하고 제기합니다. 내가 테스트 할 때 새로운 것). 수년 동안 나는 수십 개의 티켓과 패치로 몇 가지 프로젝트를 범했습니다. 이 티켓은 문서화 된 진단 단계 및 단위 테스트가 첨부 된 경우를 포함하여 적시에주의를 기울이지 않습니다.

간단히 말해, 무료로 업무를 수행 할 시간이 무제한이라고 설명합니다. ( '무료'비트를 건너 뛸 수 있으며) 원하는대로 언제든지 기여할 수 있습니다. "귀하의"프로젝트가 아니라 모든 사람의 프로젝트입니다.

"정말 죄송합니다. 좋은 생각이지만 다른 모든 작업으로 너무 바빠서 목록에 추가 할 것입니다. 프로젝트에 공헌함으로써 우리를 도와주고 싶을 것입니다. 우리는 사람들이 프로젝트를 변경하는 데 도움이되는 문서를 가지고 있습니다. 도움이 필요하면 변경 사항이 포함 된 패치를 보내 주시기 바랍니다 프로젝트 표준에 맞도록 수정해야 할 수도 있습니다. 최소한 우리에게이 작업에 대한 합법성을 제공함으로써 큰 ​​호의를 베풀고 있습니다.

물론 일단 패치를 요청하기 시작하면 티켓 시스템에 패치를 너무 오래 놓아 둔 채로 둘 수 없습니다. 많은 것을 얻는다면 이전에 사용했던 작업보다 더 통합 할 수 있습니다. 당신은 그것을 좋아하지 않을 수도 있지만, 패치가 계속 나오기를 원할 필요가 있습니다.

예의를 지키고 상황을 명확하게 설명하십시오. 다음과 같은 것은 어떻습니까?

의견을 보내 주셔서 감사합니다. 귀하의 기능은 매우 흥미롭지 만 대부분의 요청 된 기능을 제품에 구현하려는 노력에도 불구하고 모든 기능을 구현할 시간이 충분하지 않습니다. 개발자 인 경우 오픈 소스이므로 프로젝트에 참여하여 참여할 수 있습니다.

"당신은 왜 당신의 요청으로 나를 귀찮게합니까? 나는 당신을 위해 무료로 일하고 있지 않습니다.이 기능을 원한다면 직접 가서 구현하십시오"라고 말할 수는 없습니다. 사람은 비 개발자 일 수 있으며 제품 개발에 사용되는 언어 등을 모를 수 있습니다.

따라서 무례하지 않고 프로젝트에 참여하도록 제안 하고 기능을 직접 구현할 수없는 이유를 설명 할 수도 있습니다.

무례하지 않은 또 다른 방법은 아무 말도하지 않는 것입니다. 응용 프로그램 사용자가 새로운 기능을 제안하고 버그를보고 할 수있는 웹 사이트가있는 경우 우선 순위를 기준으로 항목을 정렬 할 수 있습니다 (예 : 기능이 10,000 사용자에게 요청되고 다른 기능이 10 명만 요청 된 경우) , 첫 번째가 먼저 구현 될 가능성이 있습니다.

이러한 웹 사이트에서는 며칠 또는 몇 주 후에 다른 사용자로부터 충분한지지를받지 못한 기능에 대해 항상 "직접 구현"제안을 할 수 있습니다.

요청 해 주셔서 감사합니다. 프로젝트 백 로그에 추가했으며 곧 검토 할 것입니다.

요청의 양으로 인해 모든 요청이 구현 될 것이라고 보장 할 수는 없습니다. 우리는 자원 봉사자에 의존하므로 개발자라면 시간을내어 패치를 제출하는 것을 고려 하십시오 . 그렇지 않으면, 우리는 모두 백 로그를 극복하기 위해 열심히 노력하고 있으며 가능한 한 빨리 귀하의 요청에 도달 할 것입니다.

정말 그렇게 힘들었나요?

그냥 "패치 제출"이라고 말하는 대신 좀 더 정교하게 작성해야합니다.

• 지금 당장 또는 가까운 미래에 그럴 시간이 없다는 점을 명심하십시오. 따라서 다른 사람들이 곧 구현하기를 원한다면 패치를 제공하는 것 외에는 다른 방법이 없습니다.
• 시간을내어 기능을 평가하십시오. 당신이 진심으로 그것을 좋아한다면, 그렇게 말하는 데 아무런 해가 없습니다. 사람들을 격려하십시오. 또는 기능이 실제로 불량하다고 생각되면 설명하는 데 시간이 걸립니다.
• 시작 도움말을 제공하십시오. 아무도 당신처럼 코드베이스를 모른다. 할 시간이 없지만, 어떻게하고 어떻게 시작했는지 정확히 알고있을 것입니다. 5-10 분 안에 다른 사람들이 알아낼 시간이 필요하다는 지식을 공유 할 수 있습니다. 또한 이것은 큰 그림이 우세하도록 도와줍니다. 외계인 기능을 프로젝트에 고정시키는 대신 기고자를 멋진 정수로 안내 할 수 있습니다.

여기 내가 일반적으로 말하는 것이 있습니다 ...

"흥미로운 제안이며 FooBarLib가 그렇게 할 수 있다면 멋질 것입니다. 불행히도, FooBarLib는 저를위한 여가 시간 프로젝트이므로 가까운 시일 내에 그렇게 할 수 없을 것입니다. FooBarLib에 대한 제출을 환영합니다. 따라서 직접 구현할 수 있다면 패치를 제출하십시오 (먼저 "FooBarLib에 기여하는 방법"지침을 읽어보십시오).

"패치 제출"이라고하는 멋진 방법 외에도 개발자 중심의 문서를 제공하여 다른 사람들이 실제로 기능을 원하는 이유를 쉽게 파악할 수 있습니다. 많은 프로젝트는 개발자에게 친숙하지 않으며 최소한 수천 줄의 코드와 시스템의 다른 부분에서 수 많은 작은 테스트 사례를 읽는 데 며칠이 걸립니다.

가능한 개발자에게 도움을 제공하면 기꺼이 도움을 줄 수 있습니다. 이것은 좋은 코드 문서, 흐름을 설명하는 좋은 위키 페이지 (또는 좋은 UML / 화이트 보드 다이어그램), 패치를 쉽게 받아 들일 수있는 방법을 의미합니다.

github이 다른 사람들이 프로젝트를 포크하도록 권장하는 방식을 정말 좋아합니다. 동일한 프로젝트의 여러 버전이 다른 사용자 계정으로 존재할 수 있습니다. 내가 지시하는 방향이 마음에 들지 않으면 포크하십시오. 풀 요청을 쉽게 제출할 수 있지만 수락을 기다리지 않습니다.

그래서 내 대답은 종종 포크입니다.