Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data.

Fahimeh Hajari

dblp:366/0587 · DBLP profile ↗
← Back
1ranked-venue papers
1as first author
1since 2021 · last 2024
0009-0002-8401-7581ORCID · reported

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 1 · 1 first-author · 1 since 2021

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
1 paper
Software maintenance and evolution · 61% Empirical software engineering · 39%

Topics — the 4 heaviest of 4, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Software maintenance and evolution
code review
0.812024
Factoring Expertise, Workload, and Turnover Into Code Review Recommendation · IEEE Trans. Software Eng. 2024
Empirical software engineering › developer studies
developer turnover
0.812024
Factoring Expertise, Workload, and Turnover Into Code Review Recommendation · IEEE Trans. Software Eng. 2024
Software maintenance and evolution › code review
reviewer recommendation
0.812024
Factoring Expertise, Workload, and Turnover Into Code Review Recommendation · IEEE Trans. Software Eng. 2024
Empirical software engineering
mining software repositories
0.212024
Factoring Expertise, Workload, and Turnover Into Code Review Recommendation · IEEE Trans. Software Eng. 2024

Methods — techniques the papers use, named apart from their topics

simulation · 0.8recommendation algorithms · 0.8
YearPublicationVenuePosition
2024 Factoring Expertise, Workload, and Turnover Into Code Review Recommendation
abstract
Developer turnover is inevitable on software projects and leads to knowledge loss, a reduction in productivity, and an increase in defects. Mitigation strategies to deal with turnover tend to disrupt and increase workloads for developers. In this work, we suggest that through code review recommendation we can distribute knowledge and mitigate turnover while more evenly distributing review workload. We conduct historical analyses to understand the natural concentration of review workload and the degree of knowledge spreading that is inherent in code review. Even though review workload is highly concentrated, we show that code review natural spreads knowledge thereby reducing the files at risk to turnover. Using simulation, we evaluate existing code review recommenders and develop novel recommenders to understand their impact on the level of expertise during review, the workload of reviewers, and the files at risk to turnover. Our simulations use seeded random replacement of reviewers to allow us to compare the reviewer recommenders without the confounding variation of different reviewers being replaced for each recommender. We find that prior work that assigns reviewers based on file ownership concentrates knowledge on a small group of core developers increasing the risk of knowledge loss from turnover. Recent work, WhoDo, that considers developer workload, assigns developers that are not sufficiently committed to the project and we see an increase in files at risk to turnover. We propose learning and retention aware review recommenders that when combined are effective at reducing the risk of turnover, but they unacceptably reduce the overall expertise during reviews. Combining recommenders, we develop theSofiaWLrecommender that suggests experts with low active review workload when none of the files under review are known by only one developer. In contrast, when knowledge is concentrated on one developer, it sends the review to other reviewers to spread knowledge. For the projects we study, we are able to globally increase expertise during reviews,$+3$%, reduce workload concentration,$-12$%, and reduce the files at risk,$-28$%. We make our scripts and data available in our replication package[1]. Developers can optimize for a particular outcome measure based on the needs of their project, or use our GitHub bot to automatically balance the outcomes[2].
Fahimeh Hajari, Samaneh Malmir, Ehsan Mirsaeedi, Peter C. Rigby
IEEE Trans. Software Eng.1