On 31/05/07, Travis Oliphant wrote:

2) I think it's scope should be limited to papers that describe algorithms and code that are in NumPy / SciPy / SciKits. Perhaps we could also accept papers that describe code that depends on NumPy / SciPy that is also easily available.

I think there's a place for code that doesn't fit in scipy itself but could be closely tied to it - scikits, for example, or other code that can't go in for license reasons (such as specialization).

3) I'd like to make a requirement for inclusion of new code in SciPy that it have an associated journal article describing the algorithms, design approach, etc. I don't see this journal article as being user-interface documentation for the code. I see this is as a place to describe why the code is organized as it is and to detail any algorithms that are used.

I don't think that's a good idea. It raises the barrier to contributing code (particularly for non-native English speakers), which is not something we need. Certainly every major piece of code warrants a journal article, or at least a short piece, and certainly the author should have first shot, but I think it's not unreasonable to allow the code to go in without the article being written. But (for example) I implemented the Kuiper statistic and would be happy to contribute it to scipy (once it's seen a bit more debugging), but it's quite adequately described in the literature already, so it doesn't seem worth writing an article about it. Anne M. Archibald

Hi, 1) I'd like to get it going so that we can push out an electronic issue

after the SciPy conference (in September)

That would be great for the "fame" of numpy and scipy :) 2) I think it's scope should be limited to papers that describe

algorithms and code that are in NumPy / SciPy / SciKits. Perhaps we could also accept papers that describe code that depends on NumPy / SciPy that is also easily available.

3) I'd like to make a requirement for inclusion of new code in SciPy

that it have an associated journal article describing the algorithms, design approach, etc. I don't see this journal article as being user-interface documentation for the code. I see this is as a place to describe why the code is organized as it is and to detail any algorithms that are used.

For this point, I have the same opinion as Anne : - having an equivalence between cde and article is raising the entry level, but as Anne said, some code could be somehow too trivial ? - a peer-review process implies that an article can be rejected, so the code is accepted, but not the article and vice-versa ? - perhaps encouraging new contributors to propose an article would be a solution ? 4) The purpose of the journal as I see it is to

a) provide someplace to document what is actually done in SciPy and related software. b) provide a teaching tool of numerical methods with actual "people use-it" code that would be useful to researchers, students, and professionals. c) hopefully clever new algorithms will be developed for SciPy by people using Python that could be show-cased here d) provide a peer-review publication opportunity for people who contribute to open-source software

+1 for everything, very good idea. 5) We obviously need associate editors and people willing to review

submitted articles as well as people willing to submit articles. I have two articles that can be submitted within the next two months. What do other people have?

I could talk about the design I proposed for generic optimizer, and hopefully I'll have some other generic modules that could be exposed. But it's not in scipy, and it's not an official scikit at the moment. How long should it be - some journals have limits in size, so... - ? I think I could propose one in three months - English is not my mother-tongue and I have a pressing article deadline before - It is true that I could submit this stuff to other journals, but it

seems like that doing that makes the information harder to find in the future and not easier. I'm also dissatisfied with how information exclusionary academic journals seem to be. They are catching up, but they are still not as accessible as other things available on the internet.

Given the open nature of most scientific research, it is remarkable that getting access to the information is not as easy as it should be with modern search engines (if your internet domain does not subscribe to the e-journal).

Same for me, I have a hard time figuring why the prices are so high, and that closes the door to very good articles :( Matthieu

2007/5/31, Travis Oliphant :

1) I'd like to get it going so that we can push out an electronic issue after the SciPy conference (in September)

Such a journal is a very good idea indeed. This would also support the credibility of python/scipy/numpy for an academic audience that legitimates scientific productions mostly by articles in journals.

2) I think it's scope should be limited to papers that describe algorithms and code that are in NumPy / SciPy / SciKits. Perhaps we could also accept papers that describe code that depends on NumPy / SciPy that is also easily available.

More generally, examples of uses of scipy / numpy ... would be interesting in such a journal, as well as simply the proceedings of the scipy conferences.

It is true that I could submit this stuff to other journals, but it seems like that doing that makes the information harder to find in the future and not easier. I'm also dissatisfied with how information exclusionary academic journals seem to be. They are catching up, but they are still not as accessible as other things available on the internet.

having *one* main place where much information and documentation, with peer reviewed validation, could be found is IMHO very interesting. Regards, Nicolas -- Nicolas Pettiaux - email: nicolas.pettiaux@ael.be Utiliser des formats ouverts et des logiciels libres - http://www.passeralinux.org