-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathAbstract.tex
15 lines (12 loc) · 1.75 KB
/
Abstract.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
\begin{abstract}
Merge conflicts occur when software practitioners need to work in parallel and are inevitable in software development.
Tool builders and researchers have focused on the prevention and resolution of merge conflicts, but there is little empirical knowledge about how practitioners actually approach and perform merge conflict resolution.
Without such knowledge, tool builders might be building on wrong assumptions and researchers might miss opportunities for improving the state of the art.
We conducted semi-structured interviews of 10 software practitioners across 7 organizations, including both open-source and commercial projects.
We identify the key concepts and perceptions from practitioners, which we then validated via a survey of 162 additional practitioners.
We find that practitioners are directly impacted by their perception of the complexity of the conflicting code, and may alter the timeline in which to resolve these conflicts, as well as the methods employed for conflict resolution based upon that initial perception.
%Information about conflicting code, including the history of related changes and availability of experts in that particular area of code, are crucial unmet needs for practitioners struggling with complex conflicts.
%Merge tools have been effective at addressing smaller conflicts, but do not scale in terms of usability, information presentation, or history exploration when large or complex merge conflicts arise.
Practitioners' perceptions alter the impact of tools and processes that have been designed to preemptively and efficiently resolve merge conflicts.
Understanding whether practitioners will react according to standard use cases is important when creating human-oriented tools to support development processes.
\end{abstract}