-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTitlepage.tex
56 lines (42 loc) · 3.01 KB
/
Titlepage.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
\documentclass{article}
\title{
\vspace*{-4.2\baselineskip}
{\LARGE \bfseries {The Life-Cycle of Merge Conflicts: Processes, Barriers, and Strategies}}}
\author{\large
Nicholas Nelson\\Oregon State University\\Corvallis, Oregon, USA 97331\\nelsonni@oregonstate.edu\\ORCID: 0000-0002-6365-7152\\Phone: 1-541-224-6912
\and
Caius Brindescu\\Oregon State University\\Corvallis, Oregon, USA 97331\\brindesc@oregonstate.edu\\ORCID: 0000-0003-1196-8749
\and
Shane McKee\\Oregon State University\\Corvallis, Oregon, USA 97331\\mckeesh@outlook.com
\and
Anita Sarma\\Oregon State University\\Corvallis, Oregon, USA 97331\\anita.sarma@oregonstate.edu
\and
Danny Dig\\Oregon State University\\Corvallis, Oregon, USA 97331\\daniel.dig@oregonstate.edu
}
\date{{\textbf{Keywords: } merge conflicts, resolution processes, developer perceptions, barriers, developer tools, awareness, planning, evaluation}}
%----------------------------------
\begin{document}
\maketitle
\hrule
\begin{abstract}
Merge conflicts occur when developers make concurrent changes to the same part of the code.
They are an inevitable and disruptive aspect of collaborative software development.
Thus tool builders and researchers have focused on the prevention and automatic resolution of merge conflicts.
However, there is little empirical knowledge about how developers actually monitor for merge conflicts and plan, perform, and evaluate resolutions.
Without such knowledge, tool builders might be building on the wrong assumptions and researchers might miss opportunities for improving the state of the art.
We conducted semi-structured interviews with 10 software developers across 7 organizations, including both open-source and commercial projects.
We identify key processes, techniques, and perceptions from developers, which we extend and validate via two surveys, a \emph{Barriers Survey} and a \emph{Processes Survey,} of 162 and 102 developers, respectively.
Among others, we find that developers rely on reactive strategies of monitoring for merge conflicts.
We find that developers defer responding to conflicts based on their perception of the complexity of the conflicting code and that deferring affects the workflow of the entire team.
Developers also rely on this perception to visually evaluate their merge conflict resolutions for correctness.
Finally, developers' perceptions alter the impact of tools and processes designed to preemptively and efficiently resolve merge conflicts.
Understanding their processes and perceptions can help design human-oriented tools that better support their individual development processes.
\end{abstract}
\vfill
\newpage
\end{document}
%\title{The Life-Cycle of Merge Conflicts: Processes, Barriers, and Strategies}
%\author{Nicholas Nelson \and Caius Brindescu \and Shane~McKee \and Anita Sarma \and Danny Dig}
%\institute{Nicholas Nelson \and Caius Brindescu \and Shane McKee* \and Anita Sarma \and Danny Dig
%\at Oregon State University, Corvallis, OR 97331\\\email{\{nelsonni,brindesc,anita.sarma,daniel.dig\}@oregonstate.edu, *mckeesh@outlook.com}
%}