Minor adaptions

doc/report/beginning.tex

@@ -6,7 +6,7 @@ \section{Getting Started} \label{beginning}
 
 \subsection{Building Tomboy}
 \label{building_tomboy}
-The first problems we had already at the very beginning: First of all, we had to be able to build Tomboy and the Addins that were already there before. The problem here was actually not Tomboy itself, but its integration into our IDE of choice, MonoDevelop. It turned out that there were actually project files that could be opened with our MonoDevelop, but these were very old. We had no chance to - without deeper knowledge of Tomboy itself - get the compilation working properly from within MonoDevelop. So we just compiled Tomboy the "normal" way with autoconf etc. and created a new project file for our project.
+The first problems showed up already at the very beginning: First of all, we had to be able to build Tomboy and the Addins that were already there before. The problem here was actually not Tomboy itself, but its integration into our IDE of choice, MonoDevelop. It turned out that there were actually project files that could be opened with our MonoDevelop, but these were very old. We had no chance to - without deeper knowledge of Tomboy itself - get the compilation working properly from within MonoDevelop. So we just compiled Tomboy the "normal" way with autoconf etc. and created a new project file for our project.
 
 But here we already faced the next problem: Including now only the Binary of Tomboy, and not really the sources, many new problems arose. This was because all our IDE could refer to were C\# assemblies, and no actual code or documentation. Meaning, that we had:
 \begin{itemize}
@@ -17,7 +17,7 @@ \subsection{Building Tomboy}
 \end{itemize}
 the last point sometimes needed to test the integration with our Addin.
 
-Some of these issues we could eventually address. For example, including the sources sort of "read-only" without compilation support worked and enabled auto completion and source code browsing for Tomboy. But things like debugging don't work until now, what made the development in certain situations really hard and cumbersome.
+We could eventually address some of these issues. For example, including the sources sort of "read-only" without compilation support worked and enabled auto completion and source code browsing for Tomboy. But things like debugging don't work until now, what made the development in certain situations really hard and cumbersome.
 
 \subsection{Understanding Tomboy}
 \label{understanding_tomboy}

doc/report/open_issues.tex

@@ -2,7 +2,7 @@ \section{Open Issues}
 \label{issues}
 
 This section sums up issues encountered during the process of the project that could not yet be solved.
-Some of them were introduced just before submission and therefore not discovered until after.
+Some of them were introduced just before submission and therefore not discovered until then.
 
 \begin{itemize}
 \item Unit test failure for wrong locale

doc/report/requirements.tex

@@ -58,7 +58,7 @@ \subsection{Show / hide tasks}
 
 \subsection{Testing}
 \label{testing}
-Unit testing proved to be a tricky part in our environment. We tried our best, yet we didn't manage to have complete coverage with our tests. But we think that we covered at least the most basic functionality for our Addin (namely serialization/deserialization of task list).
+Unit testing proved to be a tricky part in our environment. We tried our best, yet we didn't manage to have complete coverage with our tests. We think that we covered at least the most basic functionality for our Addin (namely serialization/deserialization of task list).
 The first problem was that our Addin was written for Tomboy and that Tomboy itself was not written with unit tests in mind (Tomboy itself had only a small number (about 10) tests in their repository but most of them outdated so they didn't run cleanly anymore). However since our Addin on most parts only relied on the Note class of Tomboy we managed to instantiate those on our own and wrote some helper classes for that. With this we were able to write all of our tests.
 Another issue is that a lot of our code is actually GUI related (like the task list behavior) or at least very tightly coupled with the GUI. And since we did not need to write tests for that and time was very short, we decided not to do it, although in our case it probably would have made sense.