Add recap boxes

src/chapter_4.md

@@ -5,14 +5,14 @@
 Dalla @fig:files-directories si può notare che i cambiamenti generici vanno ad impattare su una superficie maggiore del sistema, sia che l'analisi sia svolta al livello di files che di directories.
 Un'ulteriore aspetto interessante riguarda la varianza delle distribuzioni, infatti, indipendentemente dalla granularità dell'analisi, il dato riguardante i cambiamenti di \acl{ML} è caratterizzato da una maggiore varianza.
 
-![Percentuale di files e directories modificate in base al tipo di cambiamento](figures/files-and-directories.pdf){#fig:files-directories width=80%}
+![Percentuale di files e directories modificate in base al tipo di cambiamento](figures/files-and-directories.pdf){#fig:files-directories width=100%}
 
 Nel boxplot in @fig:imports sono invece riportati i risultati per quanto riguarda l'utilizzo di import di \ac{ML}.
 Si può notare che, indipendentemente dalla severità dell'analisi, la percentuale di file che utilizzano librerie di \acl{ML} è caratterizzata da una forte varianza.
 Ciò indica che i progetti inclusi all'interno dello studio sono di varia natura e che alcuni sono più incentrati sul \ac{ML} rispetto ad altri.
 Inoltre, considerando l'analisi *strict*, è possibile osservare come solo un $25\%$ dei progetti abbia una percentuale di files di \ac{ML} superiore al $45\%$.
 
-![Percentuale di file che utilizzano librerie di ML](figures/imports.pdf){#fig:imports width=70%}
+![Percentuale di file che utilizzano librerie di ML](figures/imports.pdf){#fig:imports width=80%}
 
 In relazione all'analisi *strict* sono stati poi analizzati i cinque progetti più \acl{ML} *intensive* per valutare eventuali caratteristiche comuni rispetto al dominio applicativo.
 Com'è possibile notare dalla @tbl:ml-intensive i vari progetti si occupano di problematiche diverse, ma in quasi tutti i casi è prevista l'estrapolazione di informazioni da delle immagini.
@@ -28,14 +28,20 @@ L'unica eccezione è data dal progetto *jdb78/pytorch-forecasting* che si occupa
 
 : Dominio applicativo dei progetti con maggior uso di librerie di \ac{ML} {#tbl:ml-intensive}
 
+\begin{tcolorbox}[colback=white, boxrule=0.3mm]
+Sia nel caso in cui l'analisi sia svolta sui file modificati, sia nel caso in cui sia svolta sugli import, il dato riguardante il \ac{ML} è caratterizzato da una forte varianza.
+Questo vuol dire che i progetti considerati nello studio sono di varia natura.
+\end{tcolorbox}
+
+\newpage
+
 ## RQ2: come sono distribuiti i bug sulle diverse fasi di ML? {#sec:rq2}
 
 Andando a confrontare la distribuzioni della fasi sui commit (@fig:count-fix-phases) rispetto alla distribuzione sulle issues (@fig:labeling-phases) è possibile notare la scomparsa della fase *data collection*.
+
 Inoltre è evidente anche la riduzione delle occorrenze di *model training* e una crescita d'importanza per quanto riguarda le fasi di *model requirements* e *model deployment*.
 Sfortunatamente i dati disponibili per questa analisi sono molto limitati (è stato possibile ricavare la fase solo per quaranta *fix*), per cui non è stato possibile effettuare delle analisi più approfondite.
 
-\newpage
-
 ![Istanze dei fix in base alla fase](figures/count-fix-phases.pdf){#fig:count-fix-phases width=70%}
 
 ## RQ3: esiste una differenza di entropy tra ML bug e altri bug? {#sec:rq3}
@@ -68,6 +74,10 @@ In entrambi i casi, però, l'*effect size* è trascurabile segno che la compless
 
 : Risultati dei test statistici per quanto riguarda l'entropia {#tbl:test-entropy}
 
+\begin{tcolorbox}[colback=white, boxrule=0.3mm]
+Non sono emerse differenze statisticamente rilevanti per quanto riguarda la complessità del processo di cambiamento.
+\end{tcolorbox}
+
 ## RQ4: come varia il livello di discussione tra ML bug e altri bug? {#sec:rq4}
 
 Osservando invece il boxplot[^boxplot-discussion] in @fig:discussion-comments si evince una differenza molto più marcata tra le due distribuzioni.
@@ -78,6 +88,8 @@ Mentre la differenza interquartile dei *fix* di \acl{ML} è compreso tra uno e c
 
 [^boxplot-discussion]: In questo caso il limite superiore è pari al $97$-$esimo$ quantile.
 
+\newpage
+
 \begin{figure}[!ht]
 \subfloat[Numero di commenti medi\label{fig:discussion-comments}]{%
 \includegraphics[width=0.45\textwidth]{src/figures/comments.pdf}
@@ -120,6 +132,11 @@ In questo caso un valore molto elevato della metrica è spesso riconducibile all
 Nel sono un esempio la issue tratta precedentemente nel caso dei commenti, ma anche la issue 125 sempre del progetto *BrikerMan/Kashgari*.
 Altre fattori che contribuiscono a spiegare questo dato sono la presenza di blocchi di errori (*mittagessen/kraken/206*) o messaggi di log utili ad inquadrare l'origine del problema (*robertmartin8/PyPortfolioOpt/177*).
 
+\begin{tcolorbox}[colback=white, boxrule=0.3mm]
+Le \emph{issues} di \acl{ML} sono caratterizzata da una maggiore discussione.
+Un valore molto elevato di parole per commento può indicare uno scambio massiccio all'interno della discussione di \emph{snippet} di codice, di log d'errore e configurazioni dell'ambiente.
+\end{tcolorbox}
+
 ## RQ5: come varia il time-to-fix tra ML bug e altri bug? {#sec:rq5}
 
 Anche in questo caso, osservando la @fig:day-to-fix, è possibile notare una netta differenza tra i *fix* di \ac{ML} e gli altri.
@@ -155,3 +172,8 @@ Questi risultati non solo confermano la differenza osservata nel boxplot, ma ci
 
 : Risultati dei test statistici per quanto riguarda il time-to-fix {#tbl:test-time-to-fix}
 
+\begin{tcolorbox}[colback=white, boxrule=0.3mm]
+Le problematiche di \acl{ML} richiedono più tempo per essere risolte.
+La bassa priorità di una \emph{issue} e la presenza di \emph{work around} sono fattori che contribuiscono a ritardare l'intervento di \emph{fix}.
+\end{tcolorbox}
+

src/metadata.yaml

@@ -25,6 +25,8 @@ numbersections: true
 eulerchapternumber: true
 floatnumbering: true
 link-citations: true
+header-includes: |
+  \usepackage{tcolorbox}
 #############
 ac-onlyused: true
 ac-title: Acronimi