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	82	the developers. We had a strategical and validating meeting with MPOG (the
83	83	former once in a month and the latter each 15th day), release plaining with the
84	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	94	In the strategical meeting we usually defined the priorities and new features
88	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	131	high view of the feature to the low view (code). This provided a way to MPOG
125	132	validated all worked done and proof the concept that work with open source
126	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
...	...
...	...	@@ -2,7 +2,7 @@
2	2	\label{sec:architecture}
3	3
4	4	At the point of view of the architecture, two main requirements was brought by
5		-the Brazilian Federal Government for the new platform were:
	5	+the Brazilian Federal Government for the new platform:
6	6
7	7	\begin{enumerate}
8	8	\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
81	81	return content from any of the applications, be it web pages, mailing
82	82	list posts, or source code.
83	83
84		-%TODO: deixar coeso daqui para baixo
	84	+% Falar do devops
	85	+\subsection{Deploy}
	86	+
	87	+The SPB platform was deployed in 7 virtual machines with different functions,
	88	+as we can see in Figure \ref{fig:architecture2}.
85	89
86	90	\begin{figure*}[hbt]
87	91	\centering
...	...	@@ -90,11 +94,6 @@ list posts, or source code.
90	94	\label{fig:architecture2}
91	95	\end{figure*}
92	96
93		-\subsection{Deploy}
94		-
95		-In real, the SPB platform was deployed in 7 virtual machines with different functions,
96		-as we can see in Figure \ref{fig:architecture2}.
97		-
98	97	The \textit{reverseproxy} handles the HTTP requests and redirects them to the
99	98	\textit{integration}, the \textit{email} sends and receives e-mails on behalf
100	99	of the platform and the \textit{monitor} keeps the entire environment tracked.
...	...