From 9c3e2e54de05e84c6e3c556e472ab517f18feb32 Mon Sep 17 00:00:00 2001 From: Susan Hert Date: Tue, 18 Sep 2001 08:03:25 +0000 Subject: [PATCH] changed link to editorial board --- .../Developers_manual/submission_process.tex | 27 ++++++++++--------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/Packages/Developers_manual/submission_process.tex b/Packages/Developers_manual/submission_process.tex index 90b7c18178d..613e967d81e 100644 --- a/Packages/Developers_manual/submission_process.tex +++ b/Packages/Developers_manual/submission_process.tex @@ -22,7 +22,7 @@ \ExternalOnly{ \chapter{Editorial Committee} } -\ccIndexMainItemBegin{editorial board} +\ccIndexMainItemBegin{editorial committee} The editorial committee is in charge of approving the inclusion of new packages @@ -41,14 +41,15 @@ in the library. This means that they assure that new contributions Software specifications and implementations should be submitted to the editorial committee for approval. This can be done by sending mail to -\ccAnchor{mailto:editor@cgal.org}{\texttt{editor@cgal.org}} indicating +the \ccAnchor{mailto:editor@cgal.org}{committee} +\lcTex{(\texttt{editor@cgal.org})} indicating where the (PostScript) documentation and code can be found. After some reasonable amount of time, you should receive feedback from the committee about the specification and what, if anything, needs to be changed. The usual procedure is that someone from the committee is assigned to be (or volunteers to be) the primary reviewer and sends -comments on the submitted package to the board and to the authors of -the package. Discussion then proceeds among the board members and the +comments on the submitted package to the committee and to the authors of +the package. Discussion then proceeds among the committee members and the authors until a consensus is reached about how the package should be modified before being accepted. When the package has been modified, the authors should again notify the editorial committee to let them @@ -60,17 +61,17 @@ The discussion of specific packages are logged on the \ccAnchor{http://www.cgal.org/Members/Editorial/}{Editorial Committee web page}% \lcTex{ (\path|http://www.cgal.org/Members/Editorial|)}. Reading the feedback given on other packages can be quite instructive as a means of -learning what the editorial board is looking for. +learning what the editorial committee is looking for. } One should write a specification for a new package \InternalOnly{(Chapter~\ref{chap:specification})} -and submit it to the editorial board for +and submit it to the editorial committee for approval before submitting the package for inclusion in the internal releases (and ideally before implementation of the package). This assures that time is not wasted in fixing code that may later be changed -due to the recommendations of the board. -However, since it can take some time for the board to process +due to the recommendations of the committee. +However, since it can take some time for the committee to process submissions, packages that are to become part of the library (as opposed to being listed as \ccAnchor{http://www.cgal.org/CEP/requirements.html}{\cgal\ Extension Packages}) @@ -78,10 +79,10 @@ can be submitted \InternalOnly{as detailed in Section~\ref{sec:electronic_submission}} before approval. Inclusion in an internal release does not ensure inclusion in a public -release. Only after approval by the board will packages be included in new +release. Only after approval by the committee will packages be included in new public releases and then only if they pass the test suite, of course. -The current members of the editorial board are: +The current members of the editorial committee are: \begin{center} \begin{tabular}{p{5cm}p{5cm}} Andreas Fabri (chair) & Bernd G\"artner \\ @@ -91,7 +92,7 @@ Dmitrii Pasechnik & Sylvain Pion \\ Remco Veltkamp & Mariette Yvinec \end{tabular} \end{center} -\ccIndexMainItemEnd{editorial board} +\ccIndexMainItemEnd{editorial committee} \InternalOnly{ \section{Electronic submission} @@ -203,7 +204,7 @@ The following is a list of reasons why a submission might fail. \noindent Requirements: \begin{itemize} - \item Submit specifications to the editorial board before submitting + \item Submit specifications to the editorial committee before submitting packages for internal releases. \item Obey the directory structure outlined in Chapter~\ref{chap:directory_structure}. \end{itemize} @@ -211,7 +212,7 @@ Requirements: \noindent Recommendations: \begin{itemize} - \item Wait for approval from the editorial board before submitting packages + \item Wait for approval from the editorial committee before submitting packages for internal releases. \end{itemize} }