From 172f3016fedf6ab37ecf9ac8e8e97ce17c030d94 Mon Sep 17 00:00:00 2001 From: Adrian Schroeter Date: Mon, 17 Sep 2012 15:28:31 -0700 Subject: [PATCH] close #129 - removed all overfull hboxes --- approach.tex | 2 +- comm-fail.tex | 4 ++-- const-meth.tex | 6 +++--- discussion.tex | 4 ++-- introduction.tex | 4 ++-- making-action.tex | 2 +- meet-rtc.tex | 8 ++++---- stc-fse.tex | 4 ++-- stcf.tex | 4 ++-- thesis.tex | 1 + 10 files changed, 20 insertions(+), 19 deletions(-) diff --git a/approach.tex b/approach.tex index 592df70..32a317c 100644 --- a/approach.tex +++ b/approach.tex @@ -50,7 +50,7 @@ \section{Generate Insights} We take this as starting point for generating insights by breaking down socio-technical networks into triples that consist of a developer pair together with how they are connected, which can be either through a technical dependencies, a social dependency, both, or none. Since we are focusing on improving the social interactions we focus on identifying those gaps (unmet coordination needs) that are most likely to increase build success. -For this purpose we split those triples derived from all socio-technical networks into two groups, those triples that originate from a socio-technical network of a failed build and those that originate from a socio-technical network of a successful build. +For this purpose we split the triples derived from all socio-technical networks into two groups, those triples that originate from a socio-technical network of a failed build and those that originate from a socio-technical network of a successful build. For each triple we can now apply statistical tests to see if a given triple is more often observed with failed or successful builds. Those that are statistically significant for failed builds should be broken by suggesting to developers to communicate. diff --git a/comm-fail.tex b/comm-fail.tex index 067b73c..fe43135 100644 --- a/comm-fail.tex +++ b/comm-fail.tex @@ -288,7 +288,7 @@ \subsection{Individual communication measures and build results} significance to differentiate between \error\ and \ok\ builds. -\subsection{Predictive power of combined measures of communication structures} +\subsection{Predictive power of measures of communication structures} We combined communication structure measures into a predictive model that classifies a team's communication structure as leading to an \error\ or \ok\ @@ -378,7 +378,7 @@ \subsection{Predictive power of combined measures of communication structures} \bottomrule \end{tabular} \end{center} -\caption{Recall and precision for \error\ and \ok\ build results using +\caption{Recall and precision for failed (\error) and successful (\ok) build results using the Bayesian classifier.} \label{tab:PredictionResultTable} \end{table} diff --git a/const-meth.tex b/const-meth.tex index 38df418..22710a9 100644 --- a/const-meth.tex +++ b/const-meth.tex @@ -212,7 +212,7 @@ \subsection{Technical Network} \begin{figure*}[t!] \centering \includegraphics[width=.7\textwidth]{figures/cochangedfiles} -\caption{Creating a technical network by connecting two developer that changed the same file.} +\caption{Creating a technical network by connecting developers that changed the same file.} \label{fig:addtechnicaledge} \end{figure*} @@ -239,7 +239,7 @@ \subsection{Technical Network} \end{description} % Example as shown in the picture -Constructing technical networks therefore follows three steps: (1) we gather all the change-sets of interest, (2) identify the relations between artifacts, (3) infer from the change-sets and the relations between the source code artifacts the relation between the artifact owners. +Constructing technical networks therefore follows three steps: (1) we gather all change-sets of interest, (2) identify the relations between artifacts, (3) infer from the change-sets and the relations between the source code artifacts the relation between the artifact owners. For example, after we selected the set of change-sets of interest we define the change-sets themselves as the source code artifact and identify the owners of those artifacts. Then we infer the relationship between those source code artifacts by relating all change-sets that changes the same source code file. And as Figure~\ref{fig:addtechnicaledge} shows this means in the case for Alfred and Bob that they are connected because both own a change-set that modifies the same file. @@ -269,7 +269,7 @@ \subsection{Socio-Technical Network} \includegraphics[width=.46\textwidth]{figures/stc-net} \label{fig:construct-combine} } - \caption{Constructing socio-technical networks from IBM Rational Team Concert data.} + \caption{Constructing socio-technical networks from the repository provided by the IBM Rational Team Concert development team.} \label{fig:construct-stc} \end{figure} diff --git a/discussion.tex b/discussion.tex index b27ceeb..6b83644 100644 --- a/discussion.tex +++ b/discussion.tex @@ -157,7 +157,7 @@ \subsection{Recommender System Design Guidelines} Our last finding points to internal conflicts within teams and among developers caused by the desire to create a flawless product under the restriction of a set of business goals such as shipping the product on time. Thus, developers often need to be reminded that they must focus their efforts on fulfilling business goals rather than on polishing the product as they see fit. Existing recommenders that use code-related metrics such as quality or productivity may shift attention away from fulfilling business goals. -To support developers in focusing on business goals, systems supporting the information-seeking behaviour of developers should be able to prioritize information related to tasks that are mission-critical to the organization, helping the team focus its attention on the most relevant problems for the upcoming release. +To support developers to focus on business goals, systems supporting the information-seeking behaviour of developers should be able to prioritize information related to tasks that are mission-critical to the organization, helping the team focus its attention on the most relevant problems for the upcoming release. \subsection{STC in real time} @@ -173,7 +173,7 @@ \section{Threats to Validity} % limited number of studies \paragraph{External Validity} -In this thesis we draw on information from observational studies (Chapter~\ref{chap:talk} and~\ref{chap:actionable}) and studies relying on development repositories (Chapter~\ref{chap:soc-net},~\ref{chap:stc-net2}, and~\ref{chap:stc-net}) that cover two development projects. +In part of this work we draw on information from observational studies (Chapters~\ref{chap:talk} and~\ref{chap:actionable}) and studies relying on development repositories (Chapters~\ref{chap:soc-net},~\ref{chap:stc-net2}, and~\ref{chap:stc-net}) that cover two development projects. Although this limits the generalizability of the findings presented as well as the validity of the inferred approach, we think that the approach still holds merit as the studies that lay the foundation for the validity of generating insights in real time are derived from and industrial project comprising more than one hundred developers at a large software corporation. This in-depth relationship created by working together with the IBM Rational Team Concert development team limits the amount of data available for the studies we presented but this in-depth relationship enables us to better interpret the collected data as well as gain a deeper understanding of the organization and their processes and how they influence the data. In the case of the in class study, we aimed to minimize the conclusions we drew to only serve as a feasibility study to demonstrate that technical networks can be constructed in real time as well as give some evidence that potential recommendations can prevented build failures from occurring. diff --git a/introduction.tex b/introduction.tex index 6cb8133..8e0ca41 100644 --- a/introduction.tex +++ b/introduction.tex @@ -54,7 +54,7 @@ \begin{description} % item 3 \item[What technical dependencies need to be met with communication?] -Although to recommend every developer to talk to every other developer about their work seems to be the easiest solution to gaining perfect socio-technical congruence coverage, as mentioned earlier, it could decrease productivity due to the heavy overhead caused by constant communication. +Although the recommendation to have every developer talk to every other developer about their work seems to be the easiest solution to gaining perfect socio-technical congruence coverage, as mentioned earlier, it could decrease productivity due to the heavy overhead caused by constant communication. To address this issue we seek out which technical dependencies exist among developers and we go one step further and try to find those technical dependencies when not accompanied by communication are the most harmful to the project. Instead of focusing on recommending changes to the source code to remove technical dependencies we focus on improving the communication among developers. @@ -62,7 +62,7 @@ Additionally as customers rarely derive any tangible benefits from re-architecting a product, there is little willingness to pay for this type of work. % item 4 -\item[How to make socio-technical congruence actionable?] Although socio-technical congruence can be continuously computed and the previously mentioned strategies can be applied in real time, they all take a more project centred perspective. +\item[How to make socio-technical congruence actionable?] Although it is possible that socio-technical congruence can be continuously computed and the previously mentioned strategies can be applied in real time, they all take a more project centred perspective. To support developers to engage in communication when necessary they need to be informed of potential issues with respect to socio-technical congruence as they arise. Building on the concept of proximity proposed by Blincoe et al~\cite{blincoe:cscw:2012}, we study in depth the development interactions of a large student project at the University of Victoria, Canada, and Aalto University, Finland, and the relation between issues and their fine grained real-time code dependencies. \end{description} diff --git a/making-action.tex b/making-action.tex index 9bd5bde..a3e3ebc 100644 --- a/making-action.tex +++ b/making-action.tex @@ -236,7 +236,7 @@ \subsection{Build Failures That Matter} \begin{table}[t!] \centering\small -\begin{tabular}{l} +\begin{tabular}{@{\hspace{2pt}}l@{\hspace{2pt}}} \toprule Angeliques Method Trace for Task ... \\% \midrule diff --git a/meet-rtc.tex b/meet-rtc.tex index ca114c5..7c3b2e1 100644 --- a/meet-rtc.tex +++ b/meet-rtc.tex @@ -53,15 +53,15 @@ \subsection{Work Items} \subsection{Planning} \begin{figure}[t] \centering -\subfloat[Planning from the Eclipse UI.]{\label{subfig:planeclipse}\includegraphics[width=.5\textwidth]{figures/meet-rtc.tex/plan-eclipse}\hspace{10pt}} -\subfloat[Planning from the Web UI.]{\label{subfig:planweb}\includegraphics[width=.5\textwidth]{figures/meet-rtc.tex/plan-web}} +\subfloat[Planning from the Eclipse UI.]{\label{subfig:planeclipse}\includegraphics[width=.48\textwidth]{figures/meet-rtc.tex/plan-eclipse}\hspace{10pt}} +\subfloat[Planning from the Web UI.]{\label{subfig:planweb}\includegraphics[width=.48\textwidth]{figures/meet-rtc.tex/plan-web}} \caption{Plans as shown by the different RTC UI's.} \label{fig:plan} \end{figure} \begin{figure}[t] \centering -\subfloat[Chars in the Eclipse UI.]{\label{subfig:charteclipse}\includegraphics[width=.5\textwidth]{figures/meet-rtc.tex/chart-eclipse}\hspace{10pt}} -\subfloat[Chars in the Web UI.]{\label{subfig:chartweb}\includegraphics[width=.5\textwidth]{figures/meet-rtc.tex/chart-web}} +\subfloat[Chars in the Eclipse UI.]{\label{subfig:charteclipse}\includegraphics[width=.48\textwidth]{figures/meet-rtc.tex/chart-eclipse}\hspace{10pt}} +\subfloat[Chars in the Web UI.]{\label{subfig:chartweb}\includegraphics[width=.48\textwidth]{figures/meet-rtc.tex/chart-web}} \caption{Charts as shown by the different RTC UI's.} \label{fig:charts} \end{figure} diff --git a/stc-fse.tex b/stc-fse.tex index 78f0254..794b3ad 100644 --- a/stc-fse.tex +++ b/stc-fse.tex @@ -181,7 +181,7 @@ \section{Analysis of Socio-Technical Gaps} \begin{enumerate} \item Identify all technical pairs from the socio-technical networks. \item For each technical pair count occurrences in socio-technical networks of -failed builds. +builds that failed. \item For each technical pair count occurrences in socio-technical networks of successful builds. \item Determine if the pair is significantly related to success or failure. @@ -498,7 +498,7 @@ \section{Results} \vspace{-1cm} \includegraphics[width=\columnwidth]{figures/builddistribution} \vspace{-.75cm} -\caption{Histogram plotting how many builds have a certain number of failure-reated technical pairs.} +\caption{Histogram of how many builds have a certain number of failure-reated technical pairs.} \label{fig:builddistribution} \end{figure} diff --git a/stcf.tex b/stcf.tex index aab2b84..38982b4 100644 --- a/stcf.tex +++ b/stcf.tex @@ -225,7 +225,7 @@ \subsection{Effects of Congruence on Build Result} The result of logistic regression indicates that the following effects are significant: The congruence~$\times$~build type effect, the congruence~$\times$~build date interaction effect, the number of work~items~$\times$~build date interaction effect, and the build date~$\times$~build type effect. In addition, the number of authors and the number of files are significant main effects, although their coefficients are lower than the interaction effects involving congruence. -In the next section we discuss the main effects and interactions effects that involve congruence affecting build probability. We discuss the effects of the non-congruence effects, including the authors, files, work~items~$\times$~date interaction effect and the date~$\times$~nightly~build effect in Section \ref{sec:otherfactors}. +In the next section we discuss the main effects and interactions effects that involve congruence affecting build probability. We discuss the effects of the non-congruence effects, including the authors, files, work~items$\times$date interaction effect and the date$\times$nightly~build effect in Section \ref{sec:otherfactors}. \subsubsection{Effects of interactions involving congruence} \label{sec:congruenceinteractions} @@ -474,7 +474,7 @@ \section{Conclusions} \item[RQ 1.2:] Does Socio-Technical Networks influence build success? \end{description} -We conducted two investigations: (1) the investigation the influence of the socio-technical congruence index on build success and (2) the investigation of gaps uncovered by socio-technical networks and their influence on build success. +We conducted two investigations: (1) the investigation of the influence of the socio-technical congruence index on build success and (2) the investigation of gaps uncovered by socio-technical networks and their influence on build success. Both avenues of investigations showed that they expose an influence on build success. These findings, especially that gaps within socio-technical networks influence build success opens the door to formulating an approach on how to leverage the concept of socio-technical congruence to improve the communication among software developers. diff --git a/thesis.tex b/thesis.tex index eaa443e..a99aa0b 100644 --- a/thesis.tex +++ b/thesis.tex @@ -12,6 +12,7 @@ \newcommand{\people}{project member} % \newcommand{\ce}{Task-related Communication} +%\overfullrule=5pt \newcommand{\jazztm}{Jazz}