@@ -199,8 +199,8 @@ \section{Working The Process}
199199day to the CDash dashboard. Developers who checked in code are expected to
200200visit the dashboard and ensure their changes are acceptable---that is, they
201201do not introduce compilation errors or warnings, or break any other tests
202- including regression, memory, PrintSelf, and Set/ Get. Again, developers are
203- expected to fix problems immediately.
202+ including regression, memory, \code { PrintSelf} , and \code { Set}/ \code { Get}.
203+ Again, developers are expected to fix problems immediately.
204204
205205The release cycle occurs a small number of times a year. This requires
206206tagging and branching the Git repository, updating documentation, and
@@ -222,7 +222,7 @@ \section{The Effectiveness of the Process}
222222The effectiveness of this process is profound. By providing immediate
223223feedback to developers through email and Web pages (e.g., the dashboard), the
224224quality of ITK is exceptionally high, especially considering the complexity
225- of the algorithms and system. Errors, when accidently introduced, are caught
225+ of the algorithms and system. Errors, when accidentally introduced, are caught
226226quickly, as compared to catching them at the point of release. To wait to the
227227point of release is to wait too long, since the causal relationship between a
228228code change or addition and a bug is lost. The process is so powerful that it
0 commit comments