Added corrections and image

Rodrigo Siqueira de Melo
1 parent 303f7df2
Showing 3 changed files with 38 additions and 8 deletions Show diff stats
opensym2017/content/04-process.tex
opensym2017/content/05-architecture.tex
opensym2017/figures/meeting_flows.png
@@ -82,7 +82,14 @@ We defined some level of meeting granularity to avoid to generate overheads to
 the developers. We had a strategical and validating meeting with MPOG (the
 former once in a month and the latter each 15th day), release plaining with the
 entire team (one per month), and finally a sprint planning (one each 15th day).
-Figure X is a diagram that represents our meeting organization.
+Figure \ref{fig:meeting} is a diagram that represents our meeting organization.
+
+\begin{figure}[hbt]
+  \centering
+    \includegraphics[width=\linewidth]{figures/meeting_flows.png}
+  \caption{Meetings cycles}
+  \label{fig:meeting}
+\end{figure}
 In the strategical meeting we usually defined the priorities and new features
 with MPOG (we always had to negotiate next steps with them). Normally the
@@ -124,3 +131,27 @@ Notice that this workflow gave to us and to the MPOG a full traceability from
 high view of the feature to the low view (code). This provided a way to MPOG
 validated all worked done and proof the concept that work with open source
 project can give a proper view to them check.
+
+\subsection{Tools for communication and management}
+
+Our team had many people worked together, and most of the seniors worked in a
+different city remotely. Also, we tried to keep our work completely clear to
+the Brazilian government and citizens interested in follow the project. To
+handle those cases, we used a set of tools to communication and other to manage
+the project.
+
+For communication between member in different places, we used: google-talk with
+tmate, IRC, and mailing-list. When one student had to work in pair with a
+senior, normally, they used google-hangout for communication and they shared a
+session with tmate which allow them to share the same terminal. For questions
+and fast discussion, we used IRC. For general notification, we used the
+mailing-list.
+
+For managing the project we used the SPB Portal to validate it by ourselves and
+because it had all the required tools. We basically create one wiki page per
+release in Gitlab, one milestone per sprint, and one or more issues for address
+one user history. With this approach we achieve two important things: keep all
+the management close to the source code and tracked every feature developed by
+the project.
+
+% Ainda falta adicionar a parte da visita dos seniors e o turno sagrado
@@ -2,7 +2,7 @@
 \label{sec:architecture}
 At the point of view of the architecture, two main requirements was brought by
-the Brazilian Federal Government for the new platform were:
+the Brazilian Federal Government for the new platform:
 \begin{enumerate}
   \item \textit{Integrate existing FOSS systems}, with minimal differences from
@@ -81,7 +81,11 @@ functionality of each application, a search in the SPB portal might
 return content from any of the applications, be it web pages, mailing
 list posts, or source code.
-%TODO: deixar coeso daqui para baixo
+% Falar do devops
+\subsection{Deploy}
+
+The SPB platform was deployed in 7 virtual machines with different functions,
+as we can see in Figure \ref{fig:architecture2}.
 \begin{figure*}[hbt]
   \centering
@@ -90,11 +94,6 @@ list posts, or source code.
   \label{fig:architecture2}
 \end{figure*}
-\subsection{Deploy}
-
-In real, the SPB platform was deployed in 7 virtual machines with different functions,
-as we can see in Figure \ref{fig:architecture2}.
-
 The \textit{reverseproxy} handles the HTTP requests and redirects them to the
 \textit{integration}, the \textit{email} sends and receives e-mails on behalf
 of the platform and the \textit{monitor} keeps the entire environment tracked.
	@@ -82,7 +82,14 @@ We defined some level of meeting granularity to avoid to generate overheads to		@@ -82,7 +82,14 @@ We defined some level of meeting granularity to avoid to generate overheads to
82	the developers. We had a strategical and validating meeting with MPOG (the	82	the developers. We had a strategical and validating meeting with MPOG (the
83	former once in a month and the latter each 15th day), release plaining with the	83	former once in a month and the latter each 15th day), release plaining with the
84	entire team (one per month), and finally a sprint planning (one each 15th day).	84	entire team (one per month), and finally a sprint planning (one each 15th day).
85	-Figure X is a diagram that represents our meeting organization.	85	+Figure \ref{fig:meeting} is a diagram that represents our meeting organization.
		86	+
		87	+\begin{figure}[hbt]
		88	+ \centering
		89	+ \includegraphics[width=\linewidth]{figures/meeting_flows.png}
		90	+ \caption{Meetings cycles}
		91	+ \label{fig:meeting}
		92	+\end{figure}
86		93
87	In the strategical meeting we usually defined the priorities and new features	94	In the strategical meeting we usually defined the priorities and new features
88	with MPOG (we always had to negotiate next steps with them). Normally the	95	with MPOG (we always had to negotiate next steps with them). Normally the
	@@ -124,3 +131,27 @@ Notice that this workflow gave to us and to the MPOG a full traceability from		@@ -124,3 +131,27 @@ Notice that this workflow gave to us and to the MPOG a full traceability from
124	high view of the feature to the low view (code). This provided a way to MPOG	131	high view of the feature to the low view (code). This provided a way to MPOG
125	validated all worked done and proof the concept that work with open source	132	validated all worked done and proof the concept that work with open source
126	project can give a proper view to them check.	133	project can give a proper view to them check.
		134	+
		135	+\subsection{Tools for communication and management}
		136	+
		137	+Our team had many people worked together, and most of the seniors worked in a
		138	+different city remotely. Also, we tried to keep our work completely clear to
		139	+the Brazilian government and citizens interested in follow the project. To
		140	+handle those cases, we used a set of tools to communication and other to manage
		141	+the project.
		142	+
		143	+For communication between member in different places, we used: google-talk with
		144	+tmate, IRC, and mailing-list. When one student had to work in pair with a
		145	+senior, normally, they used google-hangout for communication and they shared a
		146	+session with tmate which allow them to share the same terminal. For questions
		147	+and fast discussion, we used IRC. For general notification, we used the
		148	+mailing-list.
		149	+
		150	+For managing the project we used the SPB Portal to validate it by ourselves and
		151	+because it had all the required tools. We basically create one wiki page per
		152	+release in Gitlab, one milestone per sprint, and one or more issues for address
		153	+one user history. With this approach we achieve two important things: keep all
		154	+the management close to the source code and tracked every feature developed by
		155	+the project.
		156	+
		157	+% Ainda falta adicionar a parte da visita dos seniors e o turno sagrado