분석대상 선정 범위에 대한 의견

분석대상 선정 기준과는 다른 의미로 범위를 미리 정하여 데이터 추출하는게 보다 더 효율적일 것 같아 의견을 제시합니다.

Github내에 저장소 수는 4백만개 이상으로 보입니다. 각각의 저장소에 대하여 생성 날짜, star, fork, commit, contributor 등(추후에 결정할 분석대상 선정기준)을 조사하여 분석대상을 정하려고 할시, 시간과 데이터량에 대한 측면에서 굉장히 비효율적이지 않을까 생각합니다.

api를 통해 데이터를 요청할 시 생성날짜, star, fork와 같은 경우는 그 값별로 어떤 저장소가 있는지를 확인할 수 있지만, commit, contributor 같은 경우는 저장소에 따라서만 그 수를 파악할 수 있습니다.(즉, 각각의 저장소별로 commit, contributor 수를 파악해야됨)

예를 들어, star 수가 1000인 저장소가 어떤 건지, 몇개인지는 한번의 요청으로 구할 수 있지만, commit 수가 1000인 저장소는 한번의 요청으로 구할 수 없고, 모든 저장소의 commit수를 각각을 구한 다음에야 알 수 있습니다.

따라서, 어떠한 기준을 통해 분석대상 선정 범위를 설정한 후 그에 속하는 저장소 각각을 조사하여 최종 분석대상을 정하는게 좋을 것 같습니다.

우선 생각해본 범위는 전체 fork(혹은 star) 수의 50%를 차지하고 있는 상위 저장소입니다.

전체 fork 수의 50%를 차지하는 상위 저장소는 fork 98이상을 받은 저장소로 30856개가 있습니다. 아래는 star와 fork를 조사한 내용입니다.(star, fork 수가 0인 저장소는 제외하였습니다.)

star_fork

이와 같이 조사할 저장소를 미리 추린 후에 각각의 저장소별로 분석대상 선정 기준을 적용하여 최종적으로 분석대상을 설정하는 방법을 제시합니다.

api 요청 제한때문에 전체 star 수를 구하는데 대략 10시간, 전체 fork 수를 구하는데 대략 6시간정도 소요됩니다. power rule을 적용하여 전체 star수와 fork수를 추측하면 실제와 유사한 값을 빠른 시간내에 구할 수 있습니다.(너무 길어지니 자세한 내용은 생략합니다.)

데이터 탐색차원으로 star와 fork를 통해 범위를 정하였으나, 연구를 진행함에 따라 적절한 다른 기준을 정하여 범위를 설정하는 것도 방법이라 생각합니다.

아래는 전체 star와 fork를 정리한 파일입니다. github_total_star_170720.xlsx github_total_fork_170721.xlsx

worldoss / ocean

분석대상 선정 범위에 대한 의견 #11