As a hobby, I'm building recommendation system which finds related projects on GitHub.

I'm computing Jaccard index for each repository, based on users who gave stars:

$$J(A, B) = \frac{ \left\vert S(A)\cap S(B) \right\vert}{\left\vert S(A)\cup S(B)\right\vert}$$

Where $S(A)$ is set of users who gave stars to repository $A$. This works fairly well (you can play with it here), however I think it could be improved if we look at more attributes than just repository followers.

For example:

  • users who forked this repository also forked...
  • users who pushed code to this repository also pushed to...
  • users who opened issues to this repository also opened issues...
  • jaccard similarity of repository description shingles (n-grams)

What are the best practices of combining these disjoint measures into single similarity coefficient? I assume, they provide different weight towards the final coefficient. E.g. pushing code shows stronger attachment to a project than giving a star.

  • $\begingroup$ I used your recommendation system a bit and in the project I seen, the most related project, was the project itself. That is indeed true, but quite bad for the user experience. You might consider filtering out the project for the list of projects related to it. $\endgroup$ – DaL Aug 27 '15 at 6:20

What a cool project!

I like to cope with similarity problems by transforming them into classification problems.

You can see here the idea. Combining multiple similarity measures in hyperspectral images?

In the specific case of projects in git hub, I would have try to use few directions:

  • The dataset is very imbalanced - most project s are not similar to each other. That enables you to use "no similarity" as a labeling heuristic and just state the similar project as positive samples.
  • The similarity measure differ by their recall/precision base on how hard it is for the user to do a certain action. For example, giving stars is easy so it will have high recall of similar project but low precision. Pushing code will have higher precision but lower recall.
  • I didn't look at data for git hub but I suspect it is long tailed. That mean that when you will move to the not very popular project, finding users that stared two of them will lead to small numbers, with all the problems the arrive with that. You can compensate by using similarity measure that base on the code and not on the user behaviour (e.g., the programming langue used, common libraries etc.). NLP is very useful here but might require considerable amount of time comparing to adding few more user behaviour based measures.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.