의미있는 오픈 소스 기고자를 다루는 방법?

프로그래머가 귀하에게 연락하여 프로젝트에 참여하도록 요청하면 어떻게 처리합니까?

이 녀석이 좋은지 몰라요 아마도 그는 자신의 가치보다 더 어려움을 겪을 것입니다.
그는 그의 이름을 kudos를 위해 성공적인 프로젝트에 첨부하려고 시도했을 것입니다.
그는 실제로 원하지 않는 방향으로 프로젝트를 진행하려고 시도 할 수 있으며 추가 복잡성에 가치가 없다고 생각되는 기능을 추가합니다.
또는 그는 매우 유용한 기고가 일 수 있습니다. 당신은 모른다.

모르는 사람들의 요청을 어떻게 처리합니까 (GitHub에서 특히 차이가 나는 경우)? 에티켓은 무엇입니까?

open-source github

— 독주
소스

GitHub의에 당신이 그것을 마음에 들지 않으면 그를 끌어 오기 요청을하고 거부하자

— 래칫 괴물

적절한 계정 이름?

— Aren

당신이 말하는 것은 "기여자"상태라고 생각합니다. 한마디로 : 누군가 자신이 아직 기여하지 않은 것에 기여하지 마십시오. 오픈 소스 프로젝트는 누구나 작업을 수행 할 수 있다는 이점이 있으므로 그렇게하도록 결정한 다음 결정하십시오.

— 찌를

@Aren 내가 그것을 위해 여분 +=1을 얻 습니까?

— 솔로

답변:

OSS 프로젝트의 멤버십은 사람들을 인터뷰하고 선발하는 자금을 지원하는 기업 팀과는 다릅니다. 소스가 이미 있습니다 (그렇지 않으면 오픈 소스가 아닙니다). 그들에게 패치를 보내라고 지시하십시오. 패치가 좋은 경우 ( 먼저 검토 해야합니다 ) 커밋하십시오. 잠재 고객이 신뢰를 쌓고 귀중한 기여를 한 역사가 있으면 글을 쓸 수있게하십시오.

OSS 팀은 유기적으로 성장합니다. 스스로 질문을하고 시간이 지남에 따라 거리의 신념을 쌓을 수 있도록하십시오.

— 남자 이름
소스

이것을 +1하십시오. 패치는 가장 낮은 시작 장벽을 생성하므로 시작하는 가장 좋은 방법입니다. 사람이 더 많은 패치를 제공하기 시작하면 (또는 정기적으로 기고자가 됨) 풀 요청으로 전환하는 것이 더 빠르고 쉽습니다.

— Evan Plaice

실례지만 실례지만 패치와 풀 요청간에 차이가 있습니까?

— heltonbiker

이 간절한 사람이 당신에게 풀 요청을 보내 게하지 않겠습니까? 그 사람의 코드를 검토하고 비평 할 수 있습니다. 이것은 가장 간단한 해결책처럼 보입니다.

— duggiefresh
소스

어쨌든 GitHub이 작동하는 방식이 아닙니까?

— alroc

내가 추가 할 유일한 것은이 사람에게 코드를보기 전에 너무 많은 노력을 기울이지 않기 위해 첫 번째 풀 요청을 작게 요청하는 것입니다. 이 같은 "도전"에 직면했을 때, 그들은 뭔가 크고 인상적인 :-) 제출 의무 느낄 수 있습니다

— 르지 Kozielczyk

조심스럽게 다루지 않으면 크고 인상적인 것이 물건을 깨뜨릴 수 있습니다.

— ratchet freak

따라서 기여가 유용하지만 품질이 떨어지고 너무 바빠서 그를 잡기에 너무 바쁘다면 기여를 거부해도 괜찮습니까?

— 솔로

@ 솔로 : 물론입니다. 적어도 팀의 나머지 팀이 해당 코드를 배우고 특히 커밋이 커질 때까지 기고자에게 기능의 버그를 유지하고 수정하도록 기꺼이 요청하는 것도 좋습니다.

— 휴고

임시 변경 사항을 수락하고 검토하십시오. 가치가 입증되면 소스 코드 저장소에 대한 쓰기 권한을 부여하십시오.

— 로버트 하비
소스