# SoftRec: Multi-Relationship Fused Software Developer Recommendation
## 1 Introduction  
Internet-based software development model has greatly promoted the efficiency of software development. Such as online developer collaboration platforms (e.g., GitHub ([[https://github.com/](https://github.com/)]([https://github.com/](https://github.com/))), StackOverflow ([[https://stackoverflow.com/](https://stackoverflow.com/)]([https://stackoverflow.com/](https://stackoverflow.com/))), SourceForge ([[https://sourceforge.net/](https://sourceforge.net/)]([https://sourceforge.net/](https://sourceforge.net/))) and TopCoder ([[https://www.topcoder.com/](https://www.topcoder.com/)]([https://www.topcoder.com/](https://www.topcoder.com/)))) have become a prevalent paradigm for software development. They usually adopt open-collaboration mode [1, 2] with a voluntary or competitive mechanism to facilitate self-organizing collaborative software development, in which the productivity and quality greatly depends on the efficiency of developers' collaboration. For example, in the process of modern code review (MCR) [3], a developer usually submits a code change to a code review system (e.g., Gerrit ([[https://www.gerritcodereview.com/](https://www.gerritcodereview.com/)]([https://www.gerritcodereview.com/](https://www.gerritcodereview.com/))), Rietveld ([[https://en.wikipedia.org/wiki/Rietveld_](https://en.wikipedia.org/wiki/Rietveld_)]([https://en.wikipedia.org/wiki/Rietveld_](https://en.wikipedia.org/wiki/Rietveld_))(software)), Crucible ([[https://www.atlassian.com/software/crucible](https://www.atlassian.com/software/crucible)]([https://www.atlassian.com/software/crucible](https://www.atlassian.com/software/crucible)))) and recommends a set of suitable developers to review the change. Then, the reviewers would check the change and give some useful suggestions. Next, the developer will refine the change according to these suggestions and commit the change to the main branch of the version control system when the reviewers approve it. For some large open source projects, hundreds of contributors may attempt to change the code, adding new features or fixing bugs every day. These changes are submittedas pull-requests [4,5] subject to review by the whole community. However, such a mechanism makes it very difficult to find suitable developers as reviewers. For example, [PERSON] et al. found that 4%-30% of the reviews suffer from a code-reviewer assignment problem, and these reviews require an average of 12 extra days to complete [6], and more than 15% of the complaints were filed the delays in completing pull requests [7]. Similar problems are encountered in StackOverflow, one of the most successful question and answering (Q&A) open-collaboration platforms. It has over 9 million users who has posted more than 16 million questions and answers on programming. However, among those questions, only about 70% of them can be answered and closed in time and millions of questions have yet to be answered properly [1]. As a result, an automatic developer recommendation approach is urgently needed for identifying suitable developers to improve developers' collaboration efficiency. In recent years, many efforts have been made for developer recommendation. Typical approaches such as the expertise-based developer recommendation and the collaborative filtering (CF)-based developer recommendation. Usually, the expertise-based approaches [2,8] recommend developers based on the ratings of their explicit expertise (e.g., skills, contributions, activeness, workload). The CF-based approaches [4,9,10] which make recommendations based on the assumption that developers with similar historic behaviors or social relationship would behave similarly on future tasks. For example, some research [11,12] integrate the explicit social information into the recommender system and recommend developers based on their friendships. However, due to the difficulty of matching developers' expertise and willingness, together with the sparsity of developer-task explicit interactions, previous approaches have not achieved ideal results.