[opensym] Applying the Athos' review on the 'process' section

Paulo Meireles
1 parent db4810a2
Showing 1 changed file with 17 additions and 17 deletions Show diff stats
opensym2017/content/08-process.tex
@@ -14,7 +14,7 @@ have joined the project to help with the more difficult issues and to transfer
 knowledge to the students. Their main task was to provide solutions for complex
 problems, working as developers. As these professionals are very skillful and
 the project could not fund full-time work for all of them, they worked
-partially on the project. In addition, they lived in either different Brazilian
+part-time on the project. In addition, they lived in either different Brazilian
 states or other countries, which led much of the communication to be online.
 In short, our work process was based on open and collaborative software
@@ -99,9 +99,9 @@ between strategical, tactical, and operational views. We had 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 as possible to the source code and tracking every feature developed
-during the project. Our decision to use the Wiki initially was empirical, but
-later reinforced by a research conducted by Joseph Chao showing the advantage
-of using Wikis~\cite{chao2007student, opensourcestyle}.
+during the project. Initially, our decision to use the Wiki was empirical, but
+later such decision was reinforced by a research conducted by Joseph Chao
+showing the advantage of using Wikis~\cite{chao2007student, opensourcestyle}.
 \subsection{High-level Project Management and Reporting}
@@ -122,10 +122,10 @@ they stopped resisting.
 We defined some level of meeting granularity to avoid generating too much
 overhead to the developers. We had a strategical and a validating meeting with
-the Brazilian Government (the former once in a month and the latter each 15th
-day), a release planning with the entire team (one per month), and finally a
-sprint planning (one each 15th day).  Figure \ref{fig:meeting} is a diagram
-that represents our meeting organization.
+the Brazilian Government (the former once in month and the latter biweekly), a
+release planning with the entire team (one per month), and finally a sprint
+planning (biweekly).  Figure \ref{fig:meeting} is a diagram that represents our
+meeting organization.
 In the strategical meeting we usually defined the priorities and new features
 with the Brazilian Government. Normally the professors, the coach of each team,
@@ -141,13 +141,13 @@ After the strategical meeting with Brazilian Government agents, we had a
 planning phase with all teams together. In this part, each team worked together
 to convert the Government wishes into smaller parts which were represented by
 the epics of the release. Each coach was responsible for conducting the
-planning and recording it on the project Wiki. With this epic, each 15th day
-the team have documented their sprint schedule (with small achievements mapped
-to issues).
+planning and recording it on the project Wiki. With this epic, biweekly the
+team have documented their sprint schedule (with small achievements mapped to
+issues).
 To keep the Brazilian Government always updated, we invited them to work with
-us to validate the new features in progress. Normally we had a meeting each
-15th day. Basically, this was our work flow. We always kept everything
+us to validate the new features in progress. Normally we had a meeting
+biweekly. Basically, this was our work flow. We always kept everything
 extremely open to the Government (our way of working, and the one often used by
 FLOSS projects) and to the team.
@@ -158,9 +158,9 @@ especially Gitlab. Basically, we had:
   \item Project repository: we have one organization with many repositories;
   \item Wiki: each release has one Wiki page with the compilation of the
     strategical meeting;
-  \item Milestones: each milestone was used to register a user history (feature);
+  \item Milestones: each milestone was used to register a user story (feature);
   \item Issues: each sprint planning generated issues, which we associated to
-    the related milestone (feature as user history) and registered on the related Wiki page.
+    the related milestone (feature as user story) and registered on the related Wiki page.
     Finally, each developer assigned the issue to herself.
 \end{enumerate}
@@ -170,6 +170,6 @@ code).  It is important to highlight that we converged to this workflow after
 many experiments. For example, we used a tool named Redmine for organizing our
 tasks during some sprints. However, this tool revealed to be 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 was the best option for
-our case.
+realized that centralizing all the work in the SPB Portal was the best option
+for our case.