오픈 소스 프로젝트에 대한 기여는 소유자가 어떻게 관리해야합니까?

오픈 소스 프로젝트를 관리 할 때 (GitHub와 같은 서비스 사용) 다음에 어떻게 반응할까요?

누군가 새로운 기능을 추가하거나 문제를 해결하기 위해 패치를 친절하게 제출했습니다. 다음 상황 중 하나가 발생합니다.

• 소스 코드가 하나 이상의 명명 규칙 등을 충족하지 않습니다.
• 소스 코드가 특정 방식으로 향상 될 수 있다고 생각합니다. 아마도 훨씬 더 간단한 소스로 동일한 효과를 얻을 수 있거나 다른 유용한 기능이 필요할 수 있습니다.

Q1. 제출 된 소스를 변경할 수 있습니까? (GitHub에서 가능합니까?)

Q2. 제출 지침에 따라 그러한 제출을 모두 거부해야합니까?

Q3. Q2에 예라면 제대로 구현되지 않은 정말 깔끔한 아이디어는 어떻습니까? 계속해서 나만의 것을 만들 수 있습니까?

기여를 장려하고 싶지만 동시에 특정 표준을 유지하는 것이 중요합니다.

프로젝트 표준을 설명하는 문서를 아직 설정하지 않은 경우 설정하십시오. 코드를 프로젝트에 제공 할 때 중요하다고 생각하는 모든 것을 설명하십시오 .

그런 다음 코드를 제공 한 사람에게 기여에 대해 대단히 감사하고 패치를 포함 시키겠다고 설명하지만 일부 문제가 있습니다. 문서에 대한 링크를 제공하고 표시되는 특정 문제를 인용하십시오. 그런 다음 해당 담당자에게 문제를 해결하도록 요청하고 코드를 다시 제출하십시오.

기고자가 너무 많지 않고이 기고가 상당히 귀중한 경우, 패치를있는 그대로 수락 한 후 다음 커밋에서 직접 패치 부분을 다시 작성하거나 코드 형식을 확인하도록 형식을 다시 지정할 수 있습니다. — 그런 다음, 변경 사항에 대한 링크가 포함 된 이메일을 기고자에게 보냅니다. 바라건대 컨트 리뷰 터가 diff를 연구하고 다음에 더 좋은 패치를 제출하면 수정하지 않아도됩니다.

기고자 안내서 또는 코딩 스타일 문서를 아직 작성하지 않은 경우이 방법이 좋습니다 . 사실, 대부분의 기고자들이 저지르는 실수를 알아 차릴 때까지 한동안 이런 방식으로 (패치 수락 및 수정, diff 로의 이메일 링크 연결) 계속할 수 있습니다. 그런 다음 기고자 안내서 및 스타일링 안내서에 이러한 실수 만 포함 시킵니다.

이런 식으로 일을하면 Q1-Q3에 대한 답은 다음과 같습니다.

• Q1 : 예, 후속 커밋에서 제출을 편집하십시오.
• Q2 : 해당 사항 없음 (아직 가이드 라인을 작성하지 않았다고 가정)
• Q3 : 고마워 말하고 다시 쓰십시오 :-) (아마도 다음 커밋에서 어쨌든 완전히 다시 쓰면 패치를 적용하는 것이 의미가 없습니다)