[opensym] including contributions and other fixes to architecture and removing r…

…edundance on conclusion

[opensym] including contributions and other fixes to architecture and removing r…
…edundance on conclusion
Melissa Wen
1 parent 601cf83c
Showing 2 changed files with 21 additions and 42 deletions Show diff stats
opensym2017/content/06-architecture.tex
opensym2017/content/09-conclusion.tex
 \section{Architecture}
 \label{sec:architecture}
-From the point of view of the architecture, two main requirements was
-brought by the Brazilian Federal Government for the new platform:
+From the architecture point of view, two main requirements was included on the new platform by Brazilian Federal Government request. They are:
 \begin{enumerate}
-  \item \textit{Integrate existing FLOSS systems}, with minimal differences from
+  \item \textit{Integrating existing FLOSS systems} with minimal differences from
     their original versions;
-  \item \textit{Provide a consistent user interface} across the different
-    systems, as well as centralized authentication.
+  \item \textit{Providing consistent user interface} across different
+    systems as well as centralized authentication.
 \end{enumerate}
-Adopting existing FLOSS systems and minimizing locally-made changes had
-the objective of being able to upgrade to newer versions of the original
-software, benefiting from improvements and maintenance done by the
-existing project communities. Providing a consistent user interface on
-top of those different tools was needed to make the transition between
-the different systems seamless from the point of view of users, which
-would be confused by jumping through completely different interfaces
-while interacting with the portal.
-
-For the first requirement, we identified four main systems that required
-specialized teams for work in the integration process. The teams learned
-how to develop for their assigned systems and contributed to the
-original communities, so that the version we used were not significantly
-different from the original.
+The adoption of existing FLOSS systems and the minimization of their local changes had the purpose to able the platform's softwares being easily upgrade to newer versions of their original software. With this facility, the platform take advantages from the maintenance and improvements made by communities. The development of a consistent user interface aims to provide to platform users a smooth transition between differents systems . Without it, the necessity of adaptation and learning for each tool could get users confused and fatigued 
 %
-At the end of the project, the SPB portal was composed of more than ten
+For the first requirement, we have identified four main systems which would have specialized teams for work in the integration process. 
+Team members have learned how to develop for their assigned systems and to contribute to the
+original communities to align the used version with the original one.
+%
+In the end of the project, the SPB portal has combined more than ten
 systems, such as Colab, Noosfero, Gitlab, and Mezuro.
 Colab\footnote{\url{https://github.com/colab}} is a systems integration
@@ -39,10 +29,7 @@ Colab implements this integration by working as a reverse proxy for the
 integration applications, that is, all external requests pass through
 Colab before reaching them. 
 %
-Initially, Colab had support for a small set of applications (Trac, GNU
-Mailman, and Apache Lucene) and support for them was hard-coded. Our
-team evolved Colab so that it can now receive plugins that add support
-new applications without the need of changes to the Colab core.
+Initially, Colab had support for a small set of applications (Trac, GNU Mailman, and Apache Lucene) made in hard-coded. Our team have helped Colab upstream to redesign the whole architecture, enabling the development of plugins to integrate new tools. We also added a feature that allowed Colab to run asynchronous tasks, which was a major improvement for us since we were developing a complex system. We have also migrated Django(web framework used by Colab) to the latest version and worked on RevProxy (the more important dependency of Colab) to put it in a good shape, fixing many bugs.
 Noosfero\footnote{\url{http://noosfero.org}} is a software for building
@@ -51,6 +38,8 @@ networking features, it also provides publication features such as blogs
 and a general-purpose CMS (Content Management System). Most of the user
 interactions with SPB is through Noosfero: user registration, project
 home pages and documentation, and contact forms.
+%
+Noosfero was the tool that contemplated several functional requirements, therefore we have made a large number of contributions to upstream. We have helped it to migrate to the latest Rails version (web framework used by Noosfero), to enable the federation implementation (federation with other social networks) and to decouple the interface and the back-end.
 Gitlab\footnote{\url{http://gitlab.com}} is a web-based Git repository
@@ -63,6 +52,8 @@ integration and continuous deployment, flexible permissions, tracking of
 Work-in-Progress work, moving issues between projects, group-level
 milestones, creating new branches from issues, issues board, and time
 tracking.
+%
+We have contributed to Gitlab upstream with some improvements related to configuration files and with the development of a new plugin that enables user authentication in Gitlab through the REMOTE\_USER HTTP header. This plugin was needed because Colab uses this mechanism to manage the authentication.
 Mezuro\footnote{\url{http://mezuro.org/}} is a platform to
@@ -80,6 +71,8 @@ tools, allows selection and composition of metrics in a flexible manner,
 stores the metrics evolution history, presents results in a friendly
 way, as well as, allows users to customize the given interpretation
 accordingly to their own context.
+%
+During the project, we helped to modularize the Mezuro project in several independent services to minimize the amount of code to maintain it, helping to test it and grant its code quality. Currently, its computation and visualization modules use Kalibro and Prezento, respectively. They were developed into the Mezuro project and evolved during its integration to the new SPB Portal.
 \subsection{System unification and User eXperience evolution}
@@ -100,10 +93,9 @@ list posts, or source code.
   \label{fig:architecture}
 \end{figure}
-The integration of collaborative environments goes beyond functional aspects.
-Offering the population an unified experience across these environments has
-been the key to encourage the use of the platform as it reduces the perception
-of complexity. Thus, the SPB Portal information architecture was redesigned
+But integration of collaborative environments goes beyond functional aspects.
+To reduce the citizens perception of system complexity and to encourage them to use the software, a platform should offer an unified experience across its environments.
+Thus, the SPB Portal information architecture was redesigned
 to provide a transparent navigation and to reach users with different profiles.
 A process of harmonization has been employed on the interaction models of each
 tool to reduce the learning curve. At the same time, a new visual style was
@@ -10,7 +10,6 @@ based on the results of the SPB Portal project, we point out that it is
 possible to mitigate conflicts experienced in the development environment
 and to conciliate governmental and academy cultures. To summarize our main contributions, we answered in this section the three open questions those guided this paper.
-
 \textbf{Q1:} \textit{Which strategy could be used to integrate several existing
 FLOSS tools to promote the collaborative software development?}
 %
@@ -95,13 +94,6 @@ way.
 %
 And even under a potentially adverse environment, the project delivered
 the desired solution with success.
-%
-At the end of the project, we noted that the skills developed by the
-students were at the software engineering state of the art.
-After the project ended, we had team members successfully embracing
-opportunities in public, private, national, and international
-organizations, in addition to those students that
-opened their own companies.
 \textbf{L3:} \textit{Managing different organizational cultures.}
 In the beginning of the project, the Brazilian Government stakeholders
@@ -109,12 +101,7 @@ had certain expectations about the project development that, let&#39;s
 say, did not exactly match our work style based on agile and FLOSS practices.
 %
 We had to develop strategies that would support these different
-organizational cultures. The
-MP is organized in a functional hierarchical organizational structure,
-typically adopting a traditional development paradigm. Therefore, we had to
-create a translation process between our team and the MP managers who
-managed the project on their side assuming a traditional waterfall
-process.
+organizational cultures. Therefore, we have created ``translation processes'' between our team and the MP managers who managed the project on their side, assuming a traditional waterfall process.
 \textbf{L4:} \textit{Managing higher-level and lower-level goals separately.}
 During the initial phase of the project, the MP team has brought
	@@ -10,7 +10,6 @@ based on the results of the SPB Portal project, we point out that it is		@@ -10,7 +10,6 @@ based on the results of the SPB Portal project, we point out that it is
10	possible to mitigate conflicts experienced in the development environment	10	possible to mitigate conflicts experienced in the development environment
11	and to conciliate governmental and academy cultures. To summarize our main contributions, we answered in this section the three open questions those guided this paper.	11	and to conciliate governmental and academy cultures. To summarize our main contributions, we answered in this section the three open questions those guided this paper.
12		12
13	-
14	\textbf{Q1:} \textit{Which strategy could be used to integrate several existing	13	\textbf{Q1:} \textit{Which strategy could be used to integrate several existing
15	FLOSS tools to promote the collaborative software development?}	14	FLOSS tools to promote the collaborative software development?}
16	%	15	%
	@@ -95,13 +94,6 @@ way.		@@ -95,13 +94,6 @@ way.
95	%	94	%
96	And even under a potentially adverse environment, the project delivered	95	And even under a potentially adverse environment, the project delivered
97	the desired solution with success.	96	the desired solution with success.
98	-%
99	-At the end of the project, we noted that the skills developed by the
100	-students were at the software engineering state of the art.
101	-After the project ended, we had team members successfully embracing
102	-opportunities in public, private, national, and international
103	-organizations, in addition to those students that
104	-opened their own companies.
105		97
106	\textbf{L3:} \textit{Managing different organizational cultures.}	98	\textbf{L3:} \textit{Managing different organizational cultures.}
107	In the beginning of the project, the Brazilian Government stakeholders	99	In the beginning of the project, the Brazilian Government stakeholders
	@@ -109,12 +101,7 @@ had certain expectations about the project development that, let's		@@ -109,12 +101,7 @@ had certain expectations about the project development that, let's
109	say, did not exactly match our work style based on agile and FLOSS practices.	101	say, did not exactly match our work style based on agile and FLOSS practices.
110	%	102	%
111	We had to develop strategies that would support these different	103	We had to develop strategies that would support these different
112	-organizational cultures. The
113	-MP is organized in a functional hierarchical organizational structure,
114	-typically adopting a traditional development paradigm. Therefore, we had to
115	-create a translation process between our team and the MP managers who
116	-managed the project on their side assuming a traditional waterfall
117	-process.	104	+organizational cultures. Therefore, we have created ``translation processes'' between our team and the MP managers who managed the project on their side, assuming a traditional waterfall process.
118		105
119	\textbf{L4:} \textit{Managing higher-level and lower-level goals separately.}	106	\textbf{L4:} \textit{Managing higher-level and lower-level goals separately.}
120	During the initial phase of the project, the MP team has brought	107	During the initial phase of the project, the MP team has brought