scikit-image paper

[Juan Nunez-Iglesias]

Hi All,

I'm moving the discussion of the paper to the mailing list, as requested by Stefan. Here's a summary of the points so far:

* Josh brought up a Computational Science and Discovery special issue as not only a possible venue for the paper but a general renewed call to action about this paper.

* I vetoed the CSD special issue, despite having no formal power of veto =P, and suggested we opt instead for a fully open access journal, such as F1000Research.

* This and Johannes's email sparked a discussion about possible homes for it. Current suggestions:

   - F1000 Research

   - JMLR MLOSS [sklearn published here]

   - Journal of Open Research Software [mahotas published here]

   - Image Processing On Line (ipol.im)

   - Journal on Image and Video Processing (jivp.eurasipjournals.com)

* Stefan suggested as the author list, "currently active core contributors", but would certainly add more authors that have "made a substantial contribution to the package." I feel the same way and I imagine other current core devs would not object to this either. (?)

* There is a markdown template PR here:

https://github.com/scikit-image/scikit-image-paper/pull/2

Johannes gave a +1 to merging that, and I give another, so that makes +2, I'll merge following this email. =)

(I have a question about this point: for managing LaTeX papers on git, I have usually stuck to the convention of "1 sentence: 1 line". Do we want this for this paper, or wrap at 72 characters, or something else?)

I think that's everything, though I'm sure the discussion will continue!

Stefan asked me to elaborate on my suggestion of F1000. I must admit I don't know much about the other journals on the list, and would need to look into them. Things that I expect from our eventual home are:

 - open access.

 - CC or similar licensing that allows text mining applications.

Further niceties offered by F1000Res:

 - papers published immediately as preprint.

 - open peer review

 - once two reviewers have signed off on the paper, it is considered "peer reviewed". Reviewers can request modifications, and full paper and revision history is maintained.

 - peer reviewed articles are indexed by PubMed.

Essentially, the review model is quite similar to the GitHub PR process, which sounds great to me. PeerJ offers a similar (identical?) model, but is currently not LaTeX friendly, which pretty much rules it out for this.

Juan.

[Stéfan van der Walt]

On Mon, Nov 18, 2013 at 3:23 AM, Juan Nunez-Iglesias <jni....@gmail.com> wrote:
> * This and Johannes's email sparked a discussion about possible homes for
> it. Current suggestions:
> - F1000 Research

I'm a bit concerned by what I read here:

http://scholarlykitchen.sspnet.org/2013/01/15/pubmed-and-f1000-research-unclear-standards-applied-unevenly/

> - JMLR MLOSS [sklearn published here]

Impact factor is about 3.4, which at least gives some indication that
its content is valued.

> - Journal on Image and Video Processing (jivp.eurasipjournals.com)

And about 0.5 for this one.

Let's stick to using wrapped lines, otherwise editing using our normal
configurations becomes painful.

Stéfan

[Juan Nunez-Iglesias]

Hey Stéfan,

On Mon, Nov 18, 2013 at 6:13 PM, Stéfan van der Walt <ste...@sun.ac.za> wrote:

>    - F1000 Research

I'm a bit concerned by what I read here:
http://scholarlykitchen.sspnet.org/2013/01/15/pubmed-and-f1000-research-unclear-standards-applied-unevenly/

Scholarly Kitchen have it in for open access in general and seem to think there is nothing wrong with the business-as-usual model of scientific publishing. I imagine that this is not true of the present list of authors, but am happy to be corrected. Just have a quick browse of their past posts and try to find something positive about OA.

You can just read a few of Fernando Perez's blog posts, particularly the recent one about the Sloan/Moore data science initiative, to find out what I think of business-as-usual science and publishing.

Quick rebuttals of the post's two main points:

"unclear standards applied unevenly" "cynical and confusing mélange of incomplete editorial practices"

Yeah, welcome to peer review. This is true of all journals — the fact that it's not open doesn't mean it's not there.

"Yet, these rejected articles continue to be published on the F1000 Research site."

It's called a preprint. arXiv papers don't get taken down when they don't pass peer review (ditto for closed github PRs). Why should these? They are clearly marked as Rejected. F1000 Research is an experiment in openness in publishing and I think it's a worthwhile one.

Having said these things, it's definitely a risk publishing there. (My impression though is that scikit-image as a library speaks for itself and the choice of journal is a choice of what model we want to support, rather than which journal will be more prestigious.) But, more importantly, it seems that F1000 Research is indeed slanted towards the biological sciences; I was under the impression that it was a catchall journal. So, it might not be the best fit.

[rant over] =)

>    - JMLR MLOSS [sklearn published here]

Impact factor is about 3.4, which at least gives some indication that
its content is valued.

If we are going to worry about JIF, PLOS ONE has 3.7, and does accept papers from all disciplines. (You will also find a Scholarly Kitchen post about how a JIF of 3.7 is a sign that PLOS and open access are doomed.)

Currently my two top candidates then are JMLR MLOSS and PLOS ONE. (The latter does charge $1300 US per article.)

Let's stick to using wrapped lines, otherwise editing using our normal
configurations becomes painful.

Agreed.

Juan.

[Stéfan van der Walt]

On Mon, Nov 18, 2013 at 10:47 AM, Juan Nunez-Iglesias
<jni....@gmail.com> wrote:
> If we are going to worry about JIF, PLOS ONE has 3.7, and does accept papers
> from all disciplines. (You will also find a Scholarly Kitchen post about how
> a JIF of 3.7 is a sign that PLOS and open access are doomed.)

Thanks, I won't take Scholarly Kitchen too seriously then. I know
that impact factors are a lousy way (by itself) to determine where to
publish, but that's a whole other kettle of fish.

> Currently my two top candidates then are JMLR MLOSS and PLOS ONE. (The
> latter does charge $1300 US per article.)

Open access fees should not pose too much of a problem:

http://library.sun.ac.za/English/services/oa/Pages/su-oafund.aspx

Let's get started on some content!

I think we would do well to emphasize the following in the paper:

- Pythonic API
- Building block for reproducible research, use in academic world (we
need a list of publications of work that used skimage)
- Educational aspects (skimage.novice)
- Google Summer of Code contributions
- Use in industry (do we have examples here?)
- ... other ideas?

Stéfan

[Johannes Schönberger]

> Currently my two top candidates then are JMLR MLOSS and PLOS ONE.

+1

> Let's get started on some content!

+1, but I must mention that I might be short of time over the coming weeks as I am about to move to another continent, so unfortunately I have a ton of other things to do :-)

> I think we would do well to emphasize the following in the paper:
>
> - Pythonic API
> - Building block for reproducible research, use in academic world (we
> need a list of publications of work that used skimage)
> - Educational aspects (skimage.novice)
> - Google Summer of Code contributions
> - Use in industry (do we have examples here?)
> - ... other ideas?

- Extensive documentation (although the docs need some more „love“ for 0.10)
- Easy to use API for prototyping and testing algorithms (probably covered by "Pythonic API“)

I have mainly used skimage for prototyping, but did not directly mention it in a publication.

Johannes

[Adam Hughes]

It may be non-disclosable, but I know that Enthought may have some industrial examples.

[Marianne Corvellec]

Hello all,

What an exciting project!

On Monday, November 18, 2013 3:59:22 AM UTC-5, Stefan van der Walt wrote:

Let's get started on some content!

I think we would do well to emphasize the following in the paper:

- Pythonic API
- Building block for reproducible research, use in academic world (we
need a list of publications of work that used skimage)
- Educational aspects (skimage.novice)
- Google Summer of Code contributions
- Use in industry (do we have examples here?)
- ... other ideas?

I believe it would be fitting to cite Dharhas Pothina's recent work.

Stéfan (and possibly others) know more about it than I do, but it could be considered both academic and industrial.

I believe Tony S Yu would have lots to share as well. :)

Marianne

[Tony Yu]

Thanks for pinging me.

Unfortunately, the current project I'm working on isn't public (at least when I last checked). There's another enthought project that is public: I'll ask around to see if it's OK to make a direct reference to the project.

-T

[Johannes Schönberger]

So, how should we get started with this? Any roadmap / plan?

> --
> You received this message because you are subscribed to the Google Groups "scikit-image" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Stéfan van der Walt]

On Wed, Nov 20, 2013 at 11:06 AM, Johannes Schönberger <js...@demuc.de> wrote:
> So, how should we get started with this? Any roadmap / plan?

Shall we split the paper into sections, and each take responsiblity
for part of it?

Something like:

1. Introduction and motivation
2. Purpose
a) Research
b) Education
c) Industry
3. Gallery of examples
4. Development practices
5. Conclusion

Ideas welcome. A slightly more exciting structure could be more fun
to write, but this will get the job done.

Stéfan

[Johannes Schönberger]

Maybe a feature / speed comparison with other libs (primarily Matlab, maybe Mahotas,...)?

> Am 20.11.2013 um 10:50 schrieb "Stéfan van der Walt" <ste...@sun.ac.za>:
>
>> On Wed, Nov 20, 2013 at 11:06 AM, Johannes Schönberger <js...@demuc.de> wrote:

>> So, how should we get started with this? Any roadmap / plan?
>

> Shall we split the paper into sections, and each take responsiblity
> for part of it?
>
> Something like:
>
> 1. Introduction and motivation
> 2. Purpose
> a) Research
> b) Education
> c) Industry
> 3. Gallery of examples
> 4. Development practices
> 5. Conclusion
>
> Ideas welcome. A slightly more exciting structure could be more fun
> to write, but this will get the job done.
>
> Stéfan
>

[Stéfan van der Walt]

On Wed, Nov 20, 2013 at 11:55 AM, Johannes Schönberger <js...@demuc.de> wrote:
> Maybe a feature / speed comparison with other libs (primarily Matlab, maybe Mahotas,...)?

I am hesitant to do that, because we expressly decided not have
feature-hunting as a goal. Speed comparisons are fine: it will
probably show that we are comparable, but not the fastest (not
currently one of our primary aims--but that could change in the
future).

Stéfan

[Johannes Schönberger]

> I am hesitant to do that, because we expressly decided not have
> feature-hunting as a goal. Speed comparisons are fine: it will
> probably show that we are comparable, but not the fastest (not
> currently one of our primary aims--but that could change in the
> future).

Just an idea… I’m also hesitant as it is always very difficult to compare functions, which itself have different parameters and options.

> 1. Introduction and motivation
> 2. Purpose
> a) Research
> b) Education
> c) Industry
> 3. Gallery of examples
> 4. Development practices
> 5. Conclusion

Looks like a sane choice. Another idea: „Outlook & Future roadmap“?

Splitting up the sections is a good idea, I think, although the text may sound a bit conglomerate as everyone has a different style and level of writing. So, I absolutely encourage you to correct me.

Johannes

[Stéfan van der Walt]

On Wed, Nov 20, 2013 at 12:41 PM, Johannes Schönberger <js...@demuc.de> wrote:
> Splitting up the sections is a good idea, I think, although the text may sound a bit conglomerate as everyone has a different style and level of writing. So, I absolutely encourage you to correct me.

Let's do first drafts, and then review and rework one another's sections?

Stéfan

[Johannes Schönberger]

> Let's do first drafts, and then review and rework one another's sections?

+1

[Johannes Schönberger]

Any plans on how long each of those sections and the whole article should be?

[Stéfan van der Walt]

On Wed, Nov 20, 2013 at 12:46 PM, Johannes Schönberger <js...@demuc.de> wrote:
> Any plans on how long each of those sections and the whole article should be?

I was thinking around 4 to 5 pages or so?

Volunteering for sections: I will do the big picture overview
(introduction + motivation) for now.

Stéfan

[Johannes Schönberger]

> I was thinking around 4 to 5 pages or so?

Probably also a question of funding and if the journal charges for excessive page lengths...?

> Volunteering for sections: I will do the big picture overview
> (introduction + motivation) for now.
>

I could do the Development practice and parts of the gallery?

[Juan Nunez-Iglesias]

@stefanv, I've found a flaw in your structure:

=P

Section 2 sounds to me like it would be made of examples, maybe merged with 3?

I think it's worth spending a bit of time on the actual outline (e.g. bullet points on each section), before launching into writing, to avoid redundancy. We can do this directly on the github template. For example, I would add my chromosome finding example (with code) to the gallery/science applications.

Speaking of development practices, I've recently noticed that there's a bit of heterogeneity in the API, with some parts being object-oriented in style and others (most) being functional, which is my preference. Do we want to emphasise that this is the preferred style?

+1 for a roadmap section.

Juan.

[Stéfan van der Walt]

Hi Juan

On Wed, Nov 20, 2013 at 3:19 PM, Juan Nunez-Iglesias <jni....@gmail.com> wrote:
>
> @stefanv, I've found a flaw in your structure:
>

I don't quite get the joke (doh).

> I think it's worth spending a bit of time on the actual outline (e.g. bullet points on each section), before launching into writing, to avoid redundancy. We can do this directly on the github template. For example, I would add my chromosome finding example (with code) to the gallery/science applications.

Sure, make a few suggestions here then we can pen down the outline.

> Speaking of development practices, I've recently noticed that there's a bit of heterogeneity in the API, with some parts being object-oriented in style and others (most) being functional, which is my preference. Do we want to emphasise that this is the preferred style?

I think the majority of the library consists of functions, unless
there is a big benefit to doing it differently. Can you elaborate?

Stéfan

[Johannes Schönberger]

> Speaking of development practices, I've recently noticed that there's a bit of heterogeneity in the API, with some parts being object-oriented in style and others (most) being functional, which is my preference. Do we want to emphasise that this is the preferred style?

The functional style is imo the preferred style, especially for raw image processing functionality, which only takes some image and produces some output.

But there are parts where object-oriented style makes a lot of sense. I only know of the following excessive cases:

- skimage.transform.GeometricTransforms
- skimage.measure.fit.*Models
- skimage.viewer

And in some places internally, mostly where actually appropriate. But only the interface is relevant in my opinion.

I can only speak for the estimation functionality in skimage, where objects help a lot to make a sane implementation - a purely functional interface would be horribly complicated.

Maybe it’s easier to keep track of the status of the discussion for everyone with a new PR: https://github.com/scikit-image/scikit-image-paper/pull/3

Please, raise your voice for more ideas and if you are volunteering for a section :-)

[Adam Hughes]

Is there currently a preferred way to cite scikit image while this paper is in the works?

--
You received this message because you are subscribed to a topic in the Google Groups "scikit-image" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scikit-image/ReKcHGSaATU/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to scikit-image...@googlegroups.com.

[Stéfan van der Walt]

On Wed, Nov 20, 2013 at 7:52 PM, Adam Hughes <hughes...@gmail.com> wrote:
> Is there currently a preferred way to cite scikit image while this paper is
> in the works?

I think unfortunately not until we at least upload the pre-print on arxiv.

Stéfan

[Stuart Mumford]

The paper I have contributed to that uses skimage references the website.

Stuart

--

You received this message because you are subscribed to the Google Groups "scikit-image" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image...@googlegroups.com.

[Tony Yu]

On Mon, Nov 18, 2013 at 10:49 PM, Tony Yu <tsy...@gmail.com> wrote:

On Mon, Nov 18, 2013 at 8:50 PM, Marianne Corvellec <marianne....@ens-lyon.org> wrote:

<snip> 

I believe Tony S Yu would have lots to share as well. :)

 

Thanks for pinging me.

Unfortunately, the current project I'm working on isn't public (at least when I last checked). There's another enthought project that is public: I'll ask around to see if it's OK to make a direct reference to the project.

Unfortunately, it's a no-go on mentioning the specific companies we've worked with, but its OK to say something like "Enthought, Inc uses scikit-image extensively in their consulting projects related to geophysics and microscopy".

-T

[Stéfan van der Walt]

On Thu, Nov 21, 2013 at 6:39 AM, Tony Yu <tsy...@gmail.com> wrote:
> Unfortunately, it's a no-go on mentioning the specific companies we've
> worked with, but its OK to say something like "Enthought, Inc uses
> scikit-image extensively in their consulting projects related to geophysics
> and microscopy".

That's great, thank you! Could I use [1] as a reference?

Stéfan

[1] Personal communications with Tony S Yu, <insert title> [or insert
other name here]

[Tony Yu]

On Thu, Nov 21, 2013 at 12:30 AM, Stéfan van der Walt <ste...@sun.ac.za> wrote:

On Thu, Nov 21, 2013 at 6:39 AM, Tony Yu <tsy...@gmail.com> wrote:
> Unfortunately, it's a no-go on mentioning the specific companies we've
> worked with, but its OK to say something like "Enthought, Inc uses
> scikit-image extensively in their consulting projects related to geophysics
> and microscopy".

That's great, thank you!  Could I use [1] as a reference?

Oops, I forgot to reply to this. Yes, definitely.

-Tony

 

Stéfan

[1] Personal communications with Tony S Yu, <insert title> [or insert
other name here]

[Johannes Schönberger]

Ping to all involved people. what's the status in this project?

[Stéfan van der Walt]

Johannes, sorry for the delay on this; the paper is a top priority for me, and I should have quite a bit of time to work on this starting Sunday evening.

[Johannes Schönberger]

Good to hear.

Let me know how to improve the Development section and I could certainly contribute another example - not sure how many examples we want to include?

On Jan 18, 2014, at 4:30, Stéfan van der Walt <ste...@sun.ac.za> wrote:

> Johannes, sorry for the delay on this; the paper is a top priority for me, and I should have quite a bit of time to work on this starting Sunday evening.
>
>

[Juan Nunez-Iglesias]

Thanks for the ping, Johannes! I myself dropped the ball on this but ready to pick it up again! 

[Johannes Schönberger]

@Juan That'd be great :-)

[François Boulogne]

Hi,

I think we should decide where and how we write codes, in the text with
a snippet style and/or at the end with a full code.
I don't know how it depends on the journal where you want to submit the
paper. Have you reached a consensus about that?

Thank you.
Best.

--
François Boulogne.
http://www.sciunto.org
GPG fingerprint: 25F6 C971 4875 A6C1 EDD1 75C8 1AA7 216E 32D5 F22F

[Stéfan van der Walt]

On Fri, 24 Jan 2014 17:57:17 -0500, François Boulogne wrote:
> I think we should decide where and how we write codes, in the text with
> a snippet style and/or at the end with a full code.
> I don't know how it depends on the journal where you want to submit the
> paper. Have you reached a consensus about that?

If you want to show something specific, e.g. the simplicity of building a
pipeline, for which you need just 3-5 lines of code, then it should probably
go inline. If it is a longer snippet, attach it at the end or perhaps think
whether it should be included at all.

We can very easily write an IPython notebook and simply reference that from
the paper for examples.

Stéfan

[Adam Hughes]

Hi guys,

Just a curiosity following up on the notebook question:  Is there a standard practice to submitting journal articles with iPython notebooks?  We were looking to do the same with a few papers in our lab and wondered if this was common yet, if there were guidelines set forth by the journals to this regard, and if only certain journals accepted notebook as accompanying materials.

[Stéfan van der Walt]

Hi Adam

On Mon, 27 Jan 2014 12:53:49 -0800, Adam Hughes wrote:
> Just a curiosity following up on the notebook question: Is there a
> standard practice to submitting journal articles with iPython notebooks?
> We were looking to do the same with a few papers in our lab and wondered
> if this was common yet, if there were guidelines set forth by the journals
> to this regard, and if only certain journals accepted notebook as
> accompanying materials.

Perhaps have a chat to Konrad Hinsen about his ActivePapers project:

http://python.6.x6.nabble.com/Interfacing-ActivePapers-with-IPython-notebooks-td5044882.html

Regards
Stéfan

[Juan Nunez-Iglesias]

Hi all,

Although we need a paper before we need to find a home for it, I came across this blog post from PeerJ, which appears to be moving up in the world! Also, they apparently accept latex submissions, even if they don't provide a template.

http://blog.peerj.com/post/74392709695/two-reviews-of-peerj

Just thought I'd add the journal to the pile.

Juan.

Stéfan

[Juan Nunez-Iglesias]

On Tue, Jan 28, 2014 at 11:48 PM, Juan Nunez-Iglesias <jni....@gmail.com> wrote:

Also, they apparently accept latex submissions, even if they don't provide a template.

Aaaaand, on cue:

http://blog.peerj.com/post/74820148558/peerj-partners-with-writelatex

[Stéfan van der Walt]

Hi all,

Working on the scikit-image paper, I've had some further thoughts
about authorship (yes, this is much harder than writing the paper :).

I suggest the following (what I consider to be) fair guideline:

1) Anyone who contributes significantly to the writing of the paper
gets their name in the authors list
2) All other contributors are included in the "scikit-image contributors" author

To me, this feels like the fairest way to reward those who time into
writing the paper, while also giving credit to all of those whose work
is described therein. I felt uncomfortable adding all "core
contributors" to the authors list, since that concept is becoming more
and more nebulous with GitHub PRs.

I'd like to hear your thoughts.

Stéfan