[IPOL discuss] Suggested changes in Submission Procedure/Author Manual

[Miguel Colom]

Quoting Pascal Monasse <monasse at 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