답변:
다음은 프로젝트 성숙도에 대한 점검표입니다.
프로젝트가 초기 이정표에 도달 했습니까?
자체 설명 된 초기 이정표에 도달하지 않으면 코드를 추가하지 않아도됩니다. 나는 항상 자신의 프로젝트가 생산 준비되었다고 주장하는 개발자를 신뢰하고 항상 그러한 주장을 평가하려고 노력한다고 제안하지는 않지만, 소프트웨어를 버전 0.x, 알파, 베타, 출시 후보 등.
적절한 문서가 있습니까?
완벽한 프로젝트는 다음을 제공합니다.
개발자는 여전히 프로젝트에 전념하고 있습니까?
물론 기초 / 회사가 지원하는 프로젝트가 아니라면 개발자가 앞으로도 계속 노력할 것인지 알 수 없습니다. 그러나 거의 항상 다음을 확인하여 커밋되었는지 알 수 있습니다.
또한 프로젝트 성숙도에 대한 좋은 지표는 초기 이정표 이후에 참여한 활발한 개발자 인 2 세대 개발자입니다.
개발자가 접근 할 수 있습니까?
이제 더 구체적인 질문에 대해 :
속도
공개 이슈 트래커가있는 프로젝트에서 이슈를 종결하는 데 시간이 얼마나 걸리는지 확실히 확인할 것입니다. 물론 속도가 항상 품질을 의미하는 것은 아니기 때문에 아마도 닫힌 문제를 겪고 중요하다고 생각할 몇 가지를 선택하고 개발자의 응답 시간과 품질을 평가할 것입니다.
라이센스 호환성
법적인 문제에 관해서는, 사용이 라이센스와 호환되는지 100 % 확신 할 수없는 경우 오픈 소스 프로젝트를 코드베이스에 통합하지 마십시오. 확실하지 않은 경우 언제든지 프로젝트 개발자에게 문의하거나 여기를 요청할 수도 있습니다.
커뮤니티 과대 광고
항상 과대 광고를 평가해야합니다. 동료 개발자의 추천은 거의 항상 프로젝트 성숙도에 대한 충분한 지표입니다.
라이센스 호환성을 제외하고 체크리스트의 모든 항목은 선택 사항입니다. 나는 죽어 있거나 문서화되지 않은 많은 프로젝트를 내 코드에 통합했으며, 항상 특정 요구 사항과 코드가 어떻게 발전하는지에 달려 있습니다.
Yannis Rizos가 답변 한 것 외에도 가능한 한 짧은면 또는 테스트 프로젝트에서 시도해 보았습니다. 이를 통해 중요한 문제가 발생하기 전에 제품의 특징에 익숙해 질 수 있습니다. 너무 많은 코드베이스를 탐색하지 않기 때문에 프로젝트가 너무 작아서는 안됩니다. 번거 로움없이 원하는 것을 할 수 있는지 알아 보려면 스핀을 가져 가십시오. 문서와 프로젝트 커뮤니티에 대한 질문을 통해 스스로 기본 작업을 수행 할 수없는 경우보다 적합하게 지원되는 코드베이스를 찾는 것이 좋습니다. 초기 테스트가 효과가 있다면 실제 테스트를 시작할 수 있습니다. 과거에는이 문제를 해결해야했으며 처음 두 번 시도한 후에는 제작에 들어가기 전에 새로운 것을 테스트하는 규칙을 만들었습니다.
BP 현명한 : 어떤 준비 / 학습 단계 없이는 새로운 것을 소개해서는 안됩니다.