다음은 프로젝트 성숙도에 대한 점검표입니다.

프로젝트가 초기 이정표에 도달 했습니까?

자체 설명 된 초기 이정표에 도달하지 않으면 코드를 추가하지 않아도됩니다. 나는 항상 자신의 프로젝트가 생산 준비되었다고 주장하는 개발자를 신뢰하고 항상 그러한 주장을 평가하려고 노력한다고 제안하지는 않지만, 소프트웨어를 버전 0.x, 알파, 베타, 출시 후보 등.

적절한 문서가 있습니까?

완벽한 프로젝트는 다음을 제공합니다.

• 예제가 가득한 사용 설명서
• 라이브러리 인 경우 통합 / 확장 가이드
• API 문서
• 완전히 문서화 된 소스 코드
• 공개 이슈 트래커

개발자는 여전히 프로젝트에 전념하고 있습니까?

물론 기초 / 회사가 지원하는 프로젝트가 아니라면 개발자가 앞으로도 계속 노력할 것인지 알 수 없습니다. 그러나 거의 항상 다음을 확인하여 커밋되었는지 알 수 있습니다.

• 최근 커밋 활동
• 최신 기능 (버그 수정뿐만 아니라)
• 최근 문서 활동 (문서 업데이트, 블로그 게시물 등)

또한 프로젝트 성숙도에 대한 좋은 지표는 초기 이정표 이후에 참여한 활발한 개발자 인 2 세대 개발자입니다.

개발자가 접근 할 수 있습니까?

• 그들은 버그에 반응합니까?
• 일반적인 문제 추적기 외에 다른 연락 수단을 제공합니까? 이것은 체크리스트의 사소한 항목이지만 단일 개발자 프로젝트의 경우 “실종 개발자의 사례” 와 같은 경우 대체 연락 수단이 도움이 될 수 있습니다.

이제 더 구체적인 질문에 대해 :

속도

공개 이슈 트래커가있는 프로젝트에서 이슈를 종결하는 데 시간이 얼마나 걸리는지 확실히 확인할 것입니다. 물론 속도가 항상 품질을 의미하는 것은 아니기 때문에 아마도 닫힌 문제를 겪고 중요하다고 생각할 몇 가지를 선택하고 개발자의 응답 시간과 품질을 평가할 것입니다.

라이센스 호환성

법적인 문제에 관해서는, 사용이 라이센스와 호환되는지 100 % 확신 할 수없는 경우 오픈 소스 프로젝트를 코드베이스에 통합하지 마십시오. 확실하지 않은 경우 언제든지 프로젝트 개발자에게 문의하거나 여기를 요청할 수도 있습니다.

커뮤니티 과대 광고

항상 과대 광고를 평가해야합니다. 동료 개발자의 추천은 거의 항상 프로젝트 성숙도에 대한 충분한 지표입니다.

라이센스 호환성을 제외하고 체크리스트의 모든 항목은 선택 사항입니다. 나는 죽어 있거나 문서화되지 않은 많은 프로젝트를 내 코드에 통합했으며, 항상 특정 요구 사항과 코드가 어떻게 발전하는지에 달려 있습니다.

답변