Siqueiras contribution

Melissa Wen · Melissa Wen
1 parent a62adb2e
Showing 9 changed files with 119 additions and 62 deletions Show diff stats
opensym2017/content/01-introduction.tex
opensym2017/content/02-spb.tex
opensym2017/content/04-requirements.tex
opensym2017/content/05-architecture.tex
opensym2017/content/06-features.tex
opensym2017/content/08-process.tex
opensym2017/content/10-lessons.tex
opensym2017/content/11-conclusion.tex
opensym2017/spb.bib
@@ -10,9 +10,9 @@ Government released a portal named Brazilian Public Software
 goal of sharing FOSS projects developed by, or for, the Brazilian
 Government.  Additionally, the Brazilian legal instrument on software
 contracting (known as IN 04/2012) mandates that public agents must give
-priority to solutions available in the SPB Portal.  In short, the
+priority to solutions available on the SPB Portal.  In short, the
 acquisition of a proprietary solution must be explicitly justified by
-demonstrating that there is no suitable alternative in the SPB Portal.
+demonstrating that there is no suitable alternative on the SPB Portal.
 In 2013, the Brazilian Federal Court issued a ruling document
 (\textit{Acórdão 2314/2013}) about an audit survey regarding the use of
 agile methodologies in software development contracts with the public
@@ -50,7 +50,7 @@ their software available on the SPB platform.
 The concept of Brazilian Public Software goes beyond FOSS. In addition
 to being licensed under a FOSS license, a SPB needs to have explicit
 guarantees that it is a public good, and that project must be available
-in the SPB portal. Being a true public good assumes requirements that
+on the SPB portal. Being a true public good assumes requirements that
 can not be met solely by means of FOSS licensing. For example, there
 must be a relaxed trademark usage policy by the original vendor that
 does not stop eventual competitors from advertising services for that
@@ -18,27 +18,27 @@ After these 3 rounds discussing the new SPB platform, the Brazilian government
 listed about 145 requirements and developed a ``mind
 map''\footnote{\url{https://softwarepublico.gov.br/social/spb/gallery/mapaconceitual.png}}
 to guide the SPB portal evolution. In this scenario, the 10 most voted
-requirements were, for example:
+requirements were:
  
 \begin{enumerate}
  
-\item Source code repository with public access.
-\item Visit community pages without login.
-\item Distributed version control system.
-\item Scores of users and developers collaboration.
-\item Search software by features.
-\item Integration with social networks.
-\item Repository for future ideas and requirements.
-\item Friendly URL to access a public software community page.
-\item User feedback about a public software.
-\item Report of the experience about the use of a public software.
+\item Source code repository with public access;
+\item Visit community pages without login;
+\item Distributed version control system;
+\item Scores of users and developers collaboration;
+\item Search software by features;
+\item Integration with social networks;
+\item Repository for future ideas and requirements;
+\item Friendly URL to access a public software community page;
+\item User feedback about a public software;
+\item Report of the experience about the use of a public software;
  
 \end{enumerate}
  
 \begin{figure}[hbt]
   \centering
     \includegraphics[width=\linewidth]{figures/technological-requirements.png}
-  \caption{Technological requirements overview.}
+  \caption{Technological requirements.}
   \label{fig:requirements}
 \end{figure}
  
@@ -57,18 +57,18 @@ features such as:
  
 \begin{enumerate}
  
-\item An organized public software catalog.
-\item Social network environment (profiles for users, software pages, and community pages).
-\item Content Management Systems (CMS) features.
-\item Web-based Git repository manager with wiki and issue tracking features.
-\item Mailing lists and discussion forums.
+\item An organized public software catalog;
+\item Social network environment (profiles for users, software pages, and community pages);
+\item Content Management Systems (CMS) features;
+\item Web-based Git repository manager with wiki and issue tracking features;
+\item Mailing lists and discussion forums;
  
 \end{enumerate}
  
 Other requirements were also planned during the conception phase of the
 SPB evolution project, such as an integrated search engine and a
 web-based source code static analysis monitor. By analyzing all of these
-requirements, we proposed the technological requirements overview
+requirements, we proposed the technological requirements
 illustrated in Figure \ref{fig:requirements} to guide the development of
 the new SPB platform. In other words, we have designed the SPB evolution
 project based on existing FOSS tools. However, the integration of
@@ -50,17 +50,17 @@ for:
 \begin{itemize}
   \item \textit{Centralized authentication}: Users are automatically 
 identified for each application without having to enter login
-credentials on each of them.
+credentials on each of them;
   \item \textit{Visual consistency}: Colab is able to change the HTML
 code produced by the integrated applications, such as defining default
 template or reusing common HTML pages, in order to provide a unified
-interface.
+interface;
   \item \textit{Relaying of events between applications}: The
 integrated applications or Colab itself are able to trigger an action
-on another application.
+on another application;
   \item \textit{Integrated search engine}: It is possible to set up
 exactly which data needs to be indexed from each application and how
-users are directed to this information on correspondent application.
+users are directed to this information on correspondent application;
 \end{itemize}
  
 Colab implements this integration by working as a reverse proxy for the
@@ -70,9 +70,7 @@ 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. We also
-developed plugins to be used in the SPB platform: Noosfero, GitLab, and
-Mezuro.
+new applications without the need of changes to the Colab core.
  
 \subsection{Noosfero}
  
@@ -98,9 +96,9 @@ tracking.
  
 \subsection{Mezuro}
  
-Mezuro\footnote{\url{http://mezuro.org/}} is a platform to collect source code
-metrics to monitor the internal quality of software written in C, C++,
-Java, Python, Ruby, and PHP.
+Mezuro\footnote{\url{http://mezuro.org/}} \cite{mezuro_oss} is a platform to
+collect source code metrics to monitor the internal quality of software written
+in C, C++, Java, Python, Ruby, and PHP.
  
 In general, source code metrics tools also do not present a friendly way
 to interpret its results and, even more, do not follow a standardization
@@ -129,7 +127,7 @@ directing requests to one of the integrated applications. It
 post-processes responses from the applications to apply a consistent
 visual appearance, manages authentication, and provides a unified search
 functionality: instead of using the redundant restricted search
-functionality of each application, a search in the SPB portal might
+functionality of each application, a search o	n the SPB portal might
 return content from any of the applications, be it web pages, mailing
 list posts, or source code.
  
@@ -48,12 +48,15 @@ such as filters (by type of software or category), sorting and score.
  
 In order to expand the searching scope and cover more types of content, the SPB team
 developed the global search tool. This tool unifies search mechanisms
-provided by the different collaborative software used in the SPB protal. Any user can
+provided by the different collaborative software used on the SPB portal. Any user can
 find a public content in the context of social networking, mailing list and
 software development.
  
 \subsection{Software development tools}
  
+Usually, Collaborative Development Environments (CDE) demand a version control
+system, trackers, build tools, knowledge centers, and communication tools
+\cite{collaboration_tools}. 
 The new SPB also provides
 tools to encourage developers to keep source code and its
 development activity within the platform. Any created software has, by default, a
@@ -31,7 +31,7 @@ Development, and Management (MP is the Brazilian acronym). All the project
 decisions, validations, and scope definitions were made by them. In this way we
 developed software product incrementally, with releases aligned to business
 strategic objectives. As one can see, the project had many different
-kinds of stakeholders that had to be organized and synchronized.
+sort of stakeholders that had to be organized and synchronized.
  
 \subsection{Team organization}
  
@@ -45,10 +45,10 @@ basic rules which guided the project organization:
  
 \begin{enumerate}
   \item Classes have high priority for undergraduate students;
-  \item Work in pairs whenever possible (locally or remotely).
+  \item Work in pairs whenever possible (locally or remotely);
   \item There must be one morning or afternoon per week when
     \emph{everyone} should be together physically in the laboratory
-    (except of course the remote team members).
+    (except of course the remote team members);
   \item Every 3 to 4 months, the senior developers would fly in and work
     alongside the students for a few days.
 \end{enumerate}
@@ -106,7 +106,10 @@ strategical, tactical, and operational views. In a practical point of view, one
 milestone per user history (feature), and one or more issues for addressing
 each feature. With this approach we achieved two important goals: keeping all
 the management as close possible to to the source code, and tracking every
-feature developed during the project.
+feature developed during the project. Our decision to
+use Wiki initially was empirical, but later reinforced by a research conducted
+by Joseph Chao showing the advantage of using Wikis \cite{chao2007student,
+opensourcestyle}.
  
 \subsection{High-level project management and reporting}
  
@@ -128,7 +131,7 @@ diagram that represents our meeting organization.
 \begin{figure}[hbt]
   \centering
     \includegraphics[width=\linewidth]{figures/meeting_flows.png}
-  \caption{Meetings cycles}
+  \caption{Meetings cycles.}
   \label{fig:meeting}
 \end{figure}
  
@@ -160,15 +163,19 @@ To keep the track of all of those things we used the SPB itself,
 especially Gitlab. Basically, we had:
  
 \begin{enumerate}
-  \item Project repository: We have one organization with many repositories
-  \item Milestones: Each milestone was used to register a release
+  \item Project repository: We have one organization with many repositories;
+  \item Milestones: Each milestone was used to register a release;
   \item Wiki: Each release has one page on wiki with the compilation of
-    strategical meeting
+    strategical meeting;
   \item Issues: Each sprint planning generated issues, which we associated to
     the specific milestone and updated the wiki with the issue number related
     with them. Finally each developer assigned the issue to itself.
 \end{enumerate}
  
-Notice that this workflow gave us and the Brazilian government agents
-full traceability from a high level view of each feature to the lowest
-level (code).
+Notice that this workflow gave us and the Brazilian government agents full
+traceability from a high level view of each feature to the lowest level (code).
+It is important to highlight that we converge to this workflow after many
+experiments. For example, we used a tool named Redmine for organizing our tasks
+during the sprints, however, this tool revealed inefficient for our case since
+the government agents lost part of the project traceability. We realized that
+centralize all the work in the SPB portal is the best option for our case.
@@ -12,7 +12,7 @@ UnB.
 %
 They interacted with professionals that had diverse expertises, and were
 able to participate in all levels of the software development process.
-This contribted to a great learning opportunity, and for a majority of
+This contributed to a great learning opportunity, and for a majority of
 them this was their first professional experience.
  
 \textbf{The participation of experienced professionals is crucial to
@@ -11,7 +11,7 @@ platform -  developed by an heterogenous team of professors, master and
 undergraduate  students, IT professionals and governmental managers - provides 
 several modern features from the integration of more than 10 FLOSS systems.
  
-Second, the 30 months project which developed this platform, results in an
+Second, the 30 months project which developed this platform results in an
 important case that it is possible to mitigate issues seen as conflicting to IT
 development environment and between industry and academy. We shown that, as
 long as the institution can provide a healthy and challenging environment to
@@ -19,8 +19,17 @@ its students, its is possible to conciliate studies and professional training
 in universities. After the end of the project, some students successfully
 embraced opportunities in public and private sectos, within national borders
 and abroad. Some others went further and started their own companies.
-
 We also shown that, with some adaptations/"translation processes", was possible
 to conciliate agile methodologies and FOSS practices to develop software to 
 governmental organizations with functional hierarchical structures that use 
 traditional development paradigm.
+
+The SPB project represented an opportunity for us to apply many of our belief
+related to FLOSS and Agile Method. We put an enormous effort to create a
+friendly environment for everybody involved in the project, and for showing to
+the government another way to interact with FLOSS community and university. Our
+work style was extremely open and we tried to be transparent for the entire
+society. As a consequence, we believe that we still need to investigate more
+all the data produced by the project and the impacts on the students. We
+expected to conduct a post-mortem analyze in the project since we have many
+open data and we applied many concepts that still extra validation.
@@ -197,22 +197,15 @@
   year = {2003}
 }
  
-@inproceedings{chao2007,
-  added-at = {2015-11-18T00:00:00.000+0100},
-  author = {Chao, Joseph},
-  biburl = {https://www.bibsonomy.org/bibtex/261af946a27913bd7eab12c1e6aa3db3a/dblp},
-  booktitle = {CSEET},
-  ee = {http://doi.ieeecomputersociety.org/10.1109/CSEET.2007.49},
-  interhash = {9d86cf791b047bb6d9484c32cfa0ee92},
-  intrahash = {61af946a27913bd7eab12c1e6aa3db3a},
-  isbn = {0-7695-2893-7},
-  keywords = {dblp},
-  pages = {255-261},
-  publisher = {IEEE Computer Society},
-  timestamp = {2015-11-19T11:37:24.000+0100},
-  title = {Student Project Collaboration Using Wikis.},
+@inproceedings{chao2007student,
+  title={Student project collaboration using Wikis},
+  author={Chao, Joseph},
+  booktitle={Software Engineering Education \& Training, 2007. CSEET'07. 20th Conference on},
+  pages={255--261},
+  year={2007},
   url = {http://dblp.uni-trier.de/db/conf/csee/csee2007.html},
-  year = {2007}
+  publisher = {IEEE Computer Society},
+  organization={IEEE}
 }
  
 @inproceedings{tosi2015,
@@ -257,3 +250,50 @@
   note = {In: 2020 FLOSS Roadmap},
   year = {2008}
 }
+
+
+@book{refactoring,
+  title={Refactoring for software design smells: Managing technical debt},
+  author={Suryanarayana, Girish and Samarthyam, Ganesh and Sharma, Tushar},
+  year={2014},
+  publisher={Morgan Kaufmann}
+}
+
+@article{mezuro_oss,
+  title={Mezuro: Understanding source code metrics},
+  author={Guedes and Meirelles and  Manzo and Camarinha},
+  journal={International Conference on Open Source Systems},
+  volume={01},
+  year={2017},
+  publisher={OSS}
+}
+
+@article{collaboration_tools,
+  title={Collaboration tools for global software engineering},
+  author={Lanubile, Filippo and Ebert, Christof and Prikladnicki, Rafael and Vizca{\'\i}no, Aurora},
+  journal={IEEE software},
+  volume={27},
+  number={2},
+  year={2010},
+  publisher={IEEE}
+}
+
+@article{parker2007wiki,
+  title={Wiki as a teaching tool},
+  author={Parker, Kevin and Chao, Joseph},
+  journal={Interdisciplinary Journal of e-learning and Learning Objects},
+  volume={3},
+  number={1},
+  pages={57--72},
+  year={2007},
+  publisher={Informing Science Institute}
+}
+
+@inproceedings{opensourcestyle,
+  title={Open source-style collaborative development practices in commercial projects using github},
+  author={Kalliamvakou, Eirini and Damian, Daniela and Blincoe, Kelly and Singer, Leif and German, Daniel M},
+  booktitle={Proceedings of the 37th International Conference on Software Engineering-Volume 1},
+  pages={574--585},
+  year={2015},
+  organization={IEEE Press}
+}
...	...	@@ -10,9 +10,9 @@ Government released a portal named Brazilian Public Software
10	10	goal of sharing FOSS projects developed by, or for, the Brazilian
11	11	Government. Additionally, the Brazilian legal instrument on software
12	12	contracting (known as IN 04/2012) mandates that public agents must give
13		-priority to solutions available in the SPB Portal. In short, the
	13	+priority to solutions available on the SPB Portal. In short, the
14	14	acquisition of a proprietary solution must be explicitly justified by
15		-demonstrating that there is no suitable alternative in the SPB Portal.
	15	+demonstrating that there is no suitable alternative on the SPB Portal.
16	16	In 2013, the Brazilian Federal Court issued a ruling document
17	17	(\textit{Acórdão 2314/2013}) about an audit survey regarding the use of
18	18	agile methodologies in software development contracts with the public
...	...
...	...	@@ -50,7 +50,7 @@ their software available on the SPB platform.
50	50	The concept of Brazilian Public Software goes beyond FOSS. In addition
51	51	to being licensed under a FOSS license, a SPB needs to have explicit
52	52	guarantees that it is a public good, and that project must be available
53		-in the SPB portal. Being a true public good assumes requirements that
	53	+on the SPB portal. Being a true public good assumes requirements that
54	54	can not be met solely by means of FOSS licensing. For example, there
55	55	must be a relaxed trademark usage policy by the original vendor that
56	56	does not stop eventual competitors from advertising services for that
...	...
...	...	@@ -18,27 +18,27 @@ After these 3 rounds discussing the new SPB platform, the Brazilian government
18	18	listed about 145 requirements and developed a ``mind
19	19	map''\footnote{\url{https://softwarepublico.gov.br/social/spb/gallery/mapaconceitual.png}}
20	20	to guide the SPB portal evolution. In this scenario, the 10 most voted
21		-requirements were, for example:
	21	+requirements were:
22	22
23	23	\begin{enumerate}
24	24
25		-\item Source code repository with public access.
26		-\item Visit community pages without login.
27		-\item Distributed version control system.
28		-\item Scores of users and developers collaboration.
29		-\item Search software by features.
30		-\item Integration with social networks.
31		-\item Repository for future ideas and requirements.
32		-\item Friendly URL to access a public software community page.
33		-\item User feedback about a public software.
34		-\item Report of the experience about the use of a public software.
	25	+\item Source code repository with public access;
	26	+\item Visit community pages without login;
	27	+\item Distributed version control system;
	28	+\item Scores of users and developers collaboration;
	29	+\item Search software by features;
	30	+\item Integration with social networks;
	31	+\item Repository for future ideas and requirements;
	32	+\item Friendly URL to access a public software community page;
	33	+\item User feedback about a public software;
	34	+\item Report of the experience about the use of a public software;
35	35
36	36	\end{enumerate}
37	37
38	38	\begin{figure}[hbt]
39	39	\centering
40	40	\includegraphics[width=\linewidth]{figures/technological-requirements.png}
41		- \caption{Technological requirements overview.}
	41	+ \caption{Technological requirements.}
42	42	\label{fig:requirements}
43	43	\end{figure}
44	44
...	...	@@ -57,18 +57,18 @@ features such as:
57	57
58	58	\begin{enumerate}
59	59
60		-\item An organized public software catalog.
61		-\item Social network environment (profiles for users, software pages, and community pages).
62		-\item Content Management Systems (CMS) features.
63		-\item Web-based Git repository manager with wiki and issue tracking features.
64		-\item Mailing lists and discussion forums.
	60	+\item An organized public software catalog;
	61	+\item Social network environment (profiles for users, software pages, and community pages);
	62	+\item Content Management Systems (CMS) features;
	63	+\item Web-based Git repository manager with wiki and issue tracking features;
	64	+\item Mailing lists and discussion forums;
65	65
66	66	\end{enumerate}
67	67
68	68	Other requirements were also planned during the conception phase of the
69	69	SPB evolution project, such as an integrated search engine and a
70	70	web-based source code static analysis monitor. By analyzing all of these
71		-requirements, we proposed the technological requirements overview
	71	+requirements, we proposed the technological requirements
72	72	illustrated in Figure \ref{fig:requirements} to guide the development of
73	73	the new SPB platform. In other words, we have designed the SPB evolution
74	74	project based on existing FOSS tools. However, the integration of
...	...
...	...	@@ -50,17 +50,17 @@ for:
50	50	\begin{itemize}
51	51	\item \textit{Centralized authentication}: Users are automatically
52	52	identified for each application without having to enter login
53		-credentials on each of them.
	53	+credentials on each of them;
54	54	\item \textit{Visual consistency}: Colab is able to change the HTML
55	55	code produced by the integrated applications, such as defining default
56	56	template or reusing common HTML pages, in order to provide a unified
57		-interface.
	57	+interface;
58	58	\item \textit{Relaying of events between applications}: The
59	59	integrated applications or Colab itself are able to trigger an action
60		-on another application.
	60	+on another application;
61	61	\item \textit{Integrated search engine}: It is possible to set up
62	62	exactly which data needs to be indexed from each application and how
63		-users are directed to this information on correspondent application.
	63	+users are directed to this information on correspondent application;
64	64	\end{itemize}
65	65
66	66	Colab implements this integration by working as a reverse proxy for the
...	...	@@ -70,9 +70,7 @@ Colab before reaching them.
70	70	Initially, Colab had support for a small set of applications (Trac, GNU
71	71	Mailman, and Apache Lucene) and support for them was hard-coded. Our
72	72	team evolved Colab so that it can now receive plugins that add support
73		-new applications without the need of changes to the Colab core. We also
74		-developed plugins to be used in the SPB platform: Noosfero, GitLab, and
75		-Mezuro.
	73	+new applications without the need of changes to the Colab core.
76	74
77	75	\subsection{Noosfero}
78	76
...	...	@@ -98,9 +96,9 @@ tracking.
98	96
99	97	\subsection{Mezuro}
100	98
101		-Mezuro\footnote{\url{http://mezuro.org/}} is a platform to collect source code
102		-metrics to monitor the internal quality of software written in C, C++,
103		-Java, Python, Ruby, and PHP.
	99	+Mezuro\footnote{\url{http://mezuro.org/}} \cite{mezuro_oss} is a platform to
	100	+collect source code metrics to monitor the internal quality of software written
	101	+in C, C++, Java, Python, Ruby, and PHP.
104	102
105	103	In general, source code metrics tools also do not present a friendly way
106	104	to interpret its results and, even more, do not follow a standardization
...	...	@@ -129,7 +127,7 @@ directing requests to one of the integrated applications. It
129	127	post-processes responses from the applications to apply a consistent
130	128	visual appearance, manages authentication, and provides a unified search
131	129	functionality: instead of using the redundant restricted search
132		-functionality of each application, a search in the SPB portal might
	130	+functionality of each application, a search o n the SPB portal might
133	131	return content from any of the applications, be it web pages, mailing
134	132	list posts, or source code.
135	133
...	...
...	...	@@ -48,12 +48,15 @@ such as filters (by type of software or category), sorting and score.
48	48
49	49	In order to expand the searching scope and cover more types of content, the SPB team
50	50	developed the global search tool. This tool unifies search mechanisms
51		-provided by the different collaborative software used in the SPB protal. Any user can
	51	+provided by the different collaborative software used on the SPB portal. Any user can
52	52	find a public content in the context of social networking, mailing list and
53	53	software development.
54	54
55	55	\subsection{Software development tools}
56	56
	57	+Usually, Collaborative Development Environments (CDE) demand a version control
	58	+system, trackers, build tools, knowledge centers, and communication tools
	59	+\cite{collaboration_tools}.
57	60	The new SPB also provides
58	61	tools to encourage developers to keep source code and its
59	62	development activity within the platform. Any created software has, by default, a
...	...
...	...	@@ -31,7 +31,7 @@ Development, and Management (MP is the Brazilian acronym). All the project
31	31	decisions, validations, and scope definitions were made by them. In this way we
32	32	developed software product incrementally, with releases aligned to business
33	33	strategic objectives. As one can see, the project had many different
34		-kinds of stakeholders that had to be organized and synchronized.
	34	+sort of stakeholders that had to be organized and synchronized.
35	35
36	36	\subsection{Team organization}
37	37
...	...	@@ -45,10 +45,10 @@ basic rules which guided the project organization:
45	45
46	46	\begin{enumerate}
47	47	\item Classes have high priority for undergraduate students;
48		- \item Work in pairs whenever possible (locally or remotely).
	48	+ \item Work in pairs whenever possible (locally or remotely);
49	49	\item There must be one morning or afternoon per week when
50	50	\emph{everyone} should be together physically in the laboratory
51		- (except of course the remote team members).
	51	+ (except of course the remote team members);
52	52	\item Every 3 to 4 months, the senior developers would fly in and work
53	53	alongside the students for a few days.
54	54	\end{enumerate}
...	...	@@ -106,7 +106,10 @@ strategical, tactical, and operational views. In a practical point of view, one
106	106	milestone per user history (feature), and one or more issues for addressing
107	107	each feature. With this approach we achieved two important goals: keeping all
108	108	the management as close possible to to the source code, and tracking every
109		-feature developed during the project.
	109	+feature developed during the project. Our decision to
	110	+use Wiki initially was empirical, but later reinforced by a research conducted
	111	+by Joseph Chao showing the advantage of using Wikis \cite{chao2007student,
	112	+opensourcestyle}.
110	113
111	114	\subsection{High-level project management and reporting}
112	115
...	...	@@ -128,7 +131,7 @@ diagram that represents our meeting organization.
128	131	\begin{figure}[hbt]
129	132	\centering
130	133	\includegraphics[width=\linewidth]{figures/meeting_flows.png}
131		- \caption{Meetings cycles}
	134	+ \caption{Meetings cycles.}
132	135	\label{fig:meeting}
133	136	\end{figure}
134	137
...	...	@@ -160,15 +163,19 @@ To keep the track of all of those things we used the SPB itself,
160	163	especially Gitlab. Basically, we had:
161	164
162	165	\begin{enumerate}
163		- \item Project repository: We have one organization with many repositories
164		- \item Milestones: Each milestone was used to register a release
	166	+ \item Project repository: We have one organization with many repositories;
	167	+ \item Milestones: Each milestone was used to register a release;
165	168	\item Wiki: Each release has one page on wiki with the compilation of
166		- strategical meeting
	169	+ strategical meeting;
167	170	\item Issues: Each sprint planning generated issues, which we associated to
168	171	the specific milestone and updated the wiki with the issue number related
169	172	with them. Finally each developer assigned the issue to itself.
170	173	\end{enumerate}
171	174
172		-Notice that this workflow gave us and the Brazilian government agents
173		-full traceability from a high level view of each feature to the lowest
174		-level (code).
	175	+Notice that this workflow gave us and the Brazilian government agents full
	176	+traceability from a high level view of each feature to the lowest level (code).
	177	+It is important to highlight that we converge to this workflow after many
	178	+experiments. For example, we used a tool named Redmine for organizing our tasks
	179	+during the sprints, however, this tool revealed inefficient for our case since
	180	+the government agents lost part of the project traceability. We realized that
	181	+centralize all the work in the SPB portal is the best option for our case.
...	...
...	...	@@ -12,7 +12,7 @@ UnB.
12	12	%
13	13	They interacted with professionals that had diverse expertises, and were
14	14	able to participate in all levels of the software development process.
15		-This contribted to a great learning opportunity, and for a majority of
	15	+This contributed to a great learning opportunity, and for a majority of
16	16	them this was their first professional experience.
17	17
18	18	\textbf{The participation of experienced professionals is crucial to
...	...
...	...	@@ -11,7 +11,7 @@ platform - developed by an heterogenous team of professors, master and
11	11	undergraduate students, IT professionals and governmental managers - provides
12	12	several modern features from the integration of more than 10 FLOSS systems.
13	13
14		-Second, the 30 months project which developed this platform, results in an
	14	+Second, the 30 months project which developed this platform results in an
15	15	important case that it is possible to mitigate issues seen as conflicting to IT
16	16	development environment and between industry and academy. We shown that, as
17	17	long as the institution can provide a healthy and challenging environment to
...	...	@@ -19,8 +19,17 @@ its students, its is possible to conciliate studies and professional training
19	19	in universities. After the end of the project, some students successfully
20	20	embraced opportunities in public and private sectos, within national borders
21	21	and abroad. Some others went further and started their own companies.
22		-
23	22	We also shown that, with some adaptations/"translation processes", was possible
24	23	to conciliate agile methodologies and FOSS practices to develop software to
25	24	governmental organizations with functional hierarchical structures that use
26	25	traditional development paradigm.
	26	+
	27	+The SPB project represented an opportunity for us to apply many of our belief
	28	+related to FLOSS and Agile Method. We put an enormous effort to create a
	29	+friendly environment for everybody involved in the project, and for showing to
	30	+the government another way to interact with FLOSS community and university. Our
	31	+work style was extremely open and we tried to be transparent for the entire
	32	+society. As a consequence, we believe that we still need to investigate more
	33	+all the data produced by the project and the impacts on the students. We
	34	+expected to conduct a post-mortem analyze in the project since we have many
	35	+open data and we applied many concepts that still extra validation.
...	...
...	...	@@ -197,22 +197,15 @@
197	197	year = {2003}
198	198	}
199	199
200		-@inproceedings{chao2007,
201		- added-at = {2015-11-18T00:00:00.000+0100},
202		- author = {Chao, Joseph},
203		- biburl = {https://www.bibsonomy.org/bibtex/261af946a27913bd7eab12c1e6aa3db3a/dblp},
204		- booktitle = {CSEET},
205		- ee = {http://doi.ieeecomputersociety.org/10.1109/CSEET.2007.49},
206		- interhash = {9d86cf791b047bb6d9484c32cfa0ee92},
207		- intrahash = {61af946a27913bd7eab12c1e6aa3db3a},
208		- isbn = {0-7695-2893-7},
209		- keywords = {dblp},
210		- pages = {255-261},
211		- publisher = {IEEE Computer Society},
212		- timestamp = {2015-11-19T11:37:24.000+0100},
213		- title = {Student Project Collaboration Using Wikis.},
	200	+@inproceedings{chao2007student,
	201	+ title={Student project collaboration using Wikis},
	202	+ author={Chao, Joseph},
	203	+ booktitle={Software Engineering Education \& Training, 2007. CSEET'07. 20th Conference on},
	204	+ pages={255--261},
	205	+ year={2007},
214	206	url = {http://dblp.uni-trier.de/db/conf/csee/csee2007.html},
215		- year = {2007}
	207	+ publisher = {IEEE Computer Society},
	208	+ organization={IEEE}
216	209	}
217	210
218	211	@inproceedings{tosi2015,
...	...	@@ -257,3 +250,50 @@
257	250	note = {In: 2020 FLOSS Roadmap},
258	251	year = {2008}
259	252	}
	253	+
	254	+
	255	+@book{refactoring,
	256	+ title={Refactoring for software design smells: Managing technical debt},
	257	+ author={Suryanarayana, Girish and Samarthyam, Ganesh and Sharma, Tushar},
	258	+ year={2014},
	259	+ publisher={Morgan Kaufmann}
	260	+}
	261	+
	262	+@article{mezuro_oss,
	263	+ title={Mezuro: Understanding source code metrics},
	264	+ author={Guedes and Meirelles and Manzo and Camarinha},
	265	+ journal={International Conference on Open Source Systems},
	266	+ volume={01},
	267	+ year={2017},
	268	+ publisher={OSS}
	269	+}
	270	+
	271	+@article{collaboration_tools,
	272	+ title={Collaboration tools for global software engineering},
	273	+ author={Lanubile, Filippo and Ebert, Christof and Prikladnicki, Rafael and Vizca{\'\i}no, Aurora},
	274	+ journal={IEEE software},
	275	+ volume={27},
	276	+ number={2},
	277	+ year={2010},
	278	+ publisher={IEEE}
	279	+}
	280	+
	281	+@article{parker2007wiki,
	282	+ title={Wiki as a teaching tool},
	283	+ author={Parker, Kevin and Chao, Joseph},
	284	+ journal={Interdisciplinary Journal of e-learning and Learning Objects},
	285	+ volume={3},
	286	+ number={1},
	287	+ pages={57--72},
	288	+ year={2007},
	289	+ publisher={Informing Science Institute}
	290	+}
	291	+
	292	+@inproceedings{opensourcestyle,
	293	+ title={Open source-style collaborative development practices in commercial projects using github},
	294	+ author={Kalliamvakou, Eirini and Damian, Daniela and Blincoe, Kelly and Singer, Leif and German, Daniel M},
	295	+ booktitle={Proceedings of the 37th International Conference on Software Engineering-Volume 1},
	296	+ pages={574--585},
	297	+ year={2015},
	298	+ organization={IEEE Press}
	299	+}
...	...