Quoting Pascal Monasse <mona...@imagine.enpc.fr>:
Dear all,
I agree that the manuals/guidelines/web pages need serious update,
but I would
not advise to remove all the restrictions unilaterally. I answer point by
point in the following.
For sure not unilaterally. That's why I've put posted in the discuss list.
In short, I agree with what Pascal wrote.
My point is not that those rules shouldn't be followed, but my
recommendations are these:
1) We're mixing very specific rules which only apply to C/C++ with
generic requirements which apply to all codes. Thus, we should
highlight the general requirements and move all the C/C++ to a
separate section called "C/C++ recommendations".
2) The editors/reviewers should have a more active role and they
should use the recommendations and mandatory rules as a checklist.
For example, if the authors writes that their code can be compiled
directly by calling gcc, the editor/review should recommend to use
"make" instead, with the $(CC) symbol.
If the authors wrote all the code in a single messy file, they should
be recommended to split into several files to improve the overall
organization of the code, etc.
If the authors are using a library which is not accepted by IPOL, they
should be told and eventually a discussion started to accept the
library or ask the author to write more standard code.
I'm not saying that we should remove totally the C/C++ rules, but they
should be turned into recommendations and at the same time an
editor/review checklist.
The mandatory rules for all codes should be kept minimal, with links
to the recommendations, and with the active supervision of the editor.
3) The same way we could create C/C++ recommendations, we should do
the same for the other languages/frameworks such as Python or MATLAB.
I think that what we should avoid is that the authors look at our help
pages and feel that they'll never manage to have such a perfect code
that can be accepted in IPOL, with all the C/C++ normatives, the
memory usage (that probably they don't know how to measure), 32 o 64
bits, compilation in several environments, etc.
Instead, they should be guided (after submitting a more or less
correct code, of course) and the editors will tell them what is wrong
in their code and how they can improve it.
Best,
Miguel
--
IPOL - Image Processing On Line - http://ipol.im/
contact e...@ipol.im - http://www.ipol.im/meta/contact/
news+feeds twitter @IPOL_journal - http://www.ipol.im/meta/feeds/
announces annou...@list.ipol.im - http://tools.ipol.im/mm/announce/
discussions discuss@list.ipol.im - http://tools.ipol.im/mm/discuss/
