Decide on criteria for authorship

[rabernat]

Given that this filtering stuff has been discussed broadly across the CPT, we should probably try to be very clear about who is invited to join the author list.

First, let me state explicitly that I think @iangrooms is clearly the lead author, since the core novel idea is his. Plus he is doing all the work of writing up the first draft.

I see three types of contribution that would merit authorship.

• Contributions to the methodology from a theoretical point of view. We had many wide-ranging discussions on this topic which have potentially influenced where we ended up.
• Development of examples from real data (models and observations) to illustrate the method
• Contributions to the software (what will eventually be the gcm-filters package)

(Beyond this, of course all authors are expected to contribute to the manuscript writing / editing, as with any paper.)

Are we all in agreement about this? If so, I would consider broadcasting our plans to the wider CPT group in case there are others who feel like they want to be part of this.

[iangrooms]

If I recall correctly, the CPT code of conduct says that we adhere to the Vancouver/ICMJE guidelines on authorship, which are

1. Substantial contributions to the conception or design of the work; or the acquisition, analysis, or interpretation of data for the work; AND
2. Drafting the work or revising it critically for important intellectual content; AND
3. Final approval of the version to be published; AND
4. Agreement to be accountable for all aspects of the work in ensuring that questions related to the accuracy or integrity of any part of the work are appropriately investigated and resolved.

I think Ryan's three bullet points pretty much cover point 1 of the ICMJE criteria for this paper, so I'm in agreement. If no one objects I can post something to Slack and github (since neither seems to cover everyone in the CPT).

[rabernat]

Great, glad we are on the same page. In, theory, the main GitHub message board should reach everyone in the CPT. At least that's what I've been assuming...

[iangrooms]

I think we should double post, just to be safe. I've heard some complaints about people not getting messages. I think anyone in the CPT can view this repo without needing to be explicitly added, right? So I can just say in the post to take a look at this repo and the linked overleaf file to get a sense of what we're doing?

[rabernat]

I think anyone in the CPT can view this repo without needing to be explicitly added, right?

No. You have to explicitly add @ocean-eddy-cpt/members to this list https://github.com/ocean-eddy-cpt/gcm-filters-paper/settings/access

[iangrooms]

OK, I've just added the "members" team with read access, so now anyone can see what we're doing. If anyone does join the author list we can change their permissions.

[NoraLoose]

I'd just like to repeat what Ryan said above. In my opinion, @iangrooms should be the lead author of the paper. Ian, I really appreciate that you think about the careers of your early-career mentees, but I would feel very awkward to be first author on this paper (as status quo in the current draft on overleaf). The filter design ideas are all yours. But I am very excited to be a co-author!

[jbusecke]

Since I am late to the party I don't feel knowledgeable enough yet as to the order of authorship. But it seems there is a clear consensus, so that is good. Just wanted to thank you all once again for adding me to this exciting project.

[iangrooms]

I posted about this paper to the CPT org on github and also to the Slack channel, so maybe we should wait to see if anyone joins before finalizing author order. I don't mind being first author, but it is nice to put postdocs first and just have me be the corresponding author.

[rabernat]

I'll defer to whatever you all decide about author order. And I am definitely 👍 on postdoc-led papers!

[LaureZanna]

Thanks all for sharing this with the rest of the CPT!

Are you OK to invite other folks that would contribute to say more kernels for your paper?

As discussed with some of you, we are applying Gaussian filtering to CM2.6 (which is MOM5) with Arthur (my non-CPT postdoc) for our ML work (the algorithm I shared with Nora and Ian). I wanted to apply the smoothing as described by Ian and Ryan and I have been digging into MOM5 Laplacian implementation. Elizabeth is also keen to contribute. We might not be as far along as you are though.
It would be great to hear your thoughts on what contributions you would accept from the rest of us, and your timeline perhaps?

Many thanks!

[iangrooms]

I think this falls under Ryan's second bullet point. We're hoping to submit soon, maybe by the end of the month. Jake has a paper that he wants to submit, and we'd like for him to be able to cite our preprint rather than having to describe the whole filtering method in an appendix or something.

We originally discussed the possibility of 2 papers: one describing the method (this one) and one JOSS paper for the software package. It felt like we would be grubbing for citations though (people always cite both papers = twice the publications!) so decided against. We could consider re-opening that discussion so that anyone who contributes a new kernel could be on the JOSS paper. If the time frame for the "methods" paper is too fast then you could still be on the JOSS paper?

[baylorfk]

I don't see why a JOSS paper shouldn't count as a second citation. It's more work, and it's more useful: it should be encouraged and how else except extra citations? Cheers, -Baylor Baylor Fox-Kemper Professor of Earth, Environmental, and Planetary Sciences Brown University [email protected], fox-kemper.com 401-863-3979

…

On Tue, Jan 19, 2021 at 9:54 AM Ian Grooms ***@***.***> wrote: I think this falls under Ryan's second bullet point. We're hoping to submit soon, maybe by the end of the month. Jake has a paper that he wants to submit, and we'd like for him to be able to cite our preprint rather than having to describe the whole filtering method in an appendix or something. We originally discussed the possibility of 2 papers: one describing the method (this one) and one JOSS <https://joss.theoj.org/> paper for the software package. It felt like we would be grubbing for citations though (people always cite both papers = twice the publications!) so decided against. We could consider re-opening that discussion so that anyone who contributes a new kernel could be on the JOSS paper. If the time frame for the "methods" paper is too fast then you could still be on the JOSS paper? — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABY7FTBSUVTOYEYKTSHH56DS2WMKPANCNFSM4WA5FQCQ> .

[LaureZanna]

Thanks, Ian for the reply (and Baylor for the follow up). If I understood correctly, there will be a software package submitted as part of the paper, so I don't see the point in splitting in it and having two papers to be honest.
I didn't mean to re-open a discussion you already had offline with the others.
In any case, we will try to have something in the next few days to contribute.
Thanks!

[iangrooms]

We aren't going to have the software package ready when we submit; it's still at an early stage of planning how it's even going to work. See the https://github.com/ocean-eddy-cpt/gcm-filters repo and issues therein. Instead, we were hoping to have a package ready by the time the paper is accepted, so that we can add a citation in the "code availability" part of the paper.

I just spoke with Scott, who said that he and Gustavo are willing to contribute something for global MOM6. In our discussion we agreed that the current "methods" paper is already covered for examples, since Nora is developing examples from POP data and Jake has examples from altimeter data. We can of course add extra examples from CM2.6 and MOM6, but it's not strictly necessary fto illustrate the methods. I can imagine a reviewer asking why we have examples from POP, MOM5, and MOM6 data that all show the same thing. So, in agreement with Baylor's comment above, we thought it might be a good idea to have a JOSS paper for the Python package and people who contribute kernels for (e.g.) MOM5 and MOM6 can be part of that paper.

[LaureZanna]

OK, thanks a lot. I guess I misunderstood your first message on what constitute a contribution for this paper and what you are planning.

[rabernat]

Let first say that I know this a somewhat complex discussion to be having in this forum, and I appreciate everyone's openness. I think we can converge with a bit more discussion.

I am a bit confused by the direction this conversation has taken. When we met met, we decided on one paper, open to all who are planning to contribute in various ways to this filtering effort. This requires some level of trust among the authors, since we are essentially inviting authors on board now with the understanding that many substantial contributions to the software will occur after the paper is submitted.

In my experience, software-only papers do not accrue citations as heavily as traditional papers. Let me ask--how many of you python users cited numpy in your last paper?

If we decide to go the two-paper route--one about the method, another about the software--it's no longer clear to me what are the criteria for authorship on the methods paper. Is my third bullet point--"Contributions to the software (what will eventually be the gcm-filters package)"--now out of scope for this first paper?

If we decide to go the two-paper route, I would like someone to propose new authorship criteria for each paper.

[iangrooms]

I agree with @rabernat that there's a lot of uncertainty about the Python package. But I don't think @LaureZanna (or @sdbachman) was proposing to make a major contribution to the Python package. Instead, it was my impression that they were interested in coding up Laplacians for CM2.6 and NCAR/MOM6 data, and then using them to provide examples for the paper. My previous comment was that we're not really in need of examples, and that coding up a Laplacian might be a better fit for a JOSS paper.

I was the one who re-opened the idea of a JOSS paper, but maybe we should try to stick with the one-paper method if possible first. Here's an idea for how to include people using examples: @NoraLoose is already working hard on the examples listed in #1 (see #9, #8, #7), and Jake has nearly completed an example from satellite data (#13). Perhaps people who want to contribute to the examples (@LaureZanna, @sdbachman, @gustavo-marques?) could either (i) take over one of the examples that Nora is already working on, possibly using different model data (e.g. CM2.6 or NCAR/MOM6), or (ii) propose a new example that illustrates some interesting property of the filtering method that's not already covered by one of our examples.

[sdbachman]

@iangrooms is correct about the scope of what @gustavo-marques and I had offered to do. We'll participate only if the filtering group feels that our contributions would be meaningful and beneficial; we don't want to add unnecessary bloat to the paper or have anyone feel like we are freeloading in the authorship. If the group decides that examples from the two of us would not add anything of substance then we do not mind staying on the sidelines, and no offense would be taken! However, if our participation is indeed desired then please let us know how to best serve the effort.

[rabernat]

Let me try to remove some uncertainty from the concept of the python package.

• The package exists: https://github.com/ocean-eddy-cpt/gcm-filters. But it doesn't fully work yet.
• The process for adding laplacians to the package is to add them (via pull request) to this file: : https://github.com/ocean-eddy-cpt/gcm-filters/blob/master/gcm_filters/kernels.py. Although there are some details to sort out, we could start doing this now.
• For a JOSS-type paper, it does not matter whether contributions are "major" or not; anyone involved in the design, coding, testing, documenation, etc. of the package would be an author. (See JOSS authorship guidelines.) So providing a Laplacian for a specific model is certainly sufficient.
• We could easily choose to adopt the same standard for a hypothetical combined "methods + software" paper. Certainly no one from the journal would second guess our choices; it's a purely internal-to-CPT deliberation.

I see three distinct options for how to move forward.

Option 1: One Paper (Methods + Software) with liberal authorship requirements

Anyone who plans to eventually contribute to the package in the future is invited to join the paper now, despite not having really done much yet. (Of course all authors would be expected to contribute to the writing / editing and be accountable for all aspects of the work.) Here we are talking a bit of a gamble that the package will actually be ready by publication time, but I feel that is a safe bet.

Option 2: One Paper (Methods + Software) with stringent authorship requirements

Same as above, but we decide not to count hypothetical future contributions to the package (e.g. contributing a Laplacian for a specific model; helping set up the documentation) as grounds for authorship. Instead, authors must contribute something substantial now to the methods paper, such as a novel example. Folks who contribute to the package in the future, but don't rise to this threshold, do not receive any citation credit for their work. At this point, the incentive to work on the package becomes low, except for the software obsessed amongst us 🤓.

Option 3: Two Papers

@iangrooms, @NoraLoose, and @jakesteinberg write up the methods paper. At some later date, we write a paper for JOSS about the package, with a different author list.

There is no right answer here, only subjective decisions about how we want this to work.

[LaureZanna]

Thanks a lot for the replies and the info! This is very useful. Like @sdbachman said, some of us will happily contribute if you think we can contribute something useful/meaningful. If you were already set with the paper as is, sorry we misunderstood! Of course, no offense/ hard feelings at all no matter what is decided. If you tell us which way you are going with options listed above by @rabernat, then we can communicate more efficiently with our postdocs.

[iangrooms]

In response to @rabernat's comment, I don't think we should do option 1. Most journals do officially adhere to ICMJE/COPE authorship requirements, even if it's left up to the authors to enforce, so watering down requirements would be suspect. There's also the problem that people might become authors with the intention of contributing to the package, and then fail to actually make any contributions.

I'm fine with option 2, and my previous comment outlines how people might contribute in that scenario. My original response to @LaureZanna was based on not knowing precisely what kind of example she expected to contribute, and I filled in the details with a negative interpretation, that anything contributed would be redundant (I apologize!).

In my most recent comment I tried to put this genie back in the bottle, but on further consideration I'm leaning towards option 3 again. As @rabernat says, people don't usually cite software, but as a CPT we could make sure that any paper we publish using spatial filtering cites the package, and maybe start a trend that way. Since the package is progressing a lot slower than the paper, splitting things up would allow more people the opportunity to contribute to the package. If we go the route of option 3, I am still not opposed to having people contribute examples to the methods paper as outlined above.

[rabernat]

👍 Sounds good Ian! Thanks to everyone for having the patience to work through this discussion.

I am continuing to work on the package and can volunteer to coordinate the JOSS paper.

[LaureZanna]

Thanks for your patience and the thoughtful replies (and sorry for the delay, I was nicely distracted by today's events!)

My over-optimistic idea was that we could provide:

• Something related to the software package: a kernel base on MOM5 data using the Laplacian from the model code (which is pretty complicated for the velocities !!!). Maybe you had the same issue with POP too. Of course, this point is moot, given that the package will now be split from the methods. We will work with @rabernat and @jbusecke on that.

• We also wanted to produce an evaluation of the subgrid eddy momentum with the different filters (with MOM5 data since we have already done the Gaussian filtering with Arthur), given that you are referring to papers that have used both boxcar and Gaussian filters for this quantity. Since we have to evaluate the sub-grid momentum as part of the CPT - we have closures that are anti-viscous in the momentum equation- this is important to get this part "right" sort-of-speak. I have done much work on that topic, including showing the differences by comparing coarse-graining and Gaussian filters for eddy momentum in a very idealized context. Therefore, as a CPT, I thought that having this diagnostic would end the discussion (rather than my group writing another paper in which I say that I agree or disagree with your paper). That being said, it might be unrealistic to attempt this calculation in just a few days since you want to submit now, or maybe you are right that it would not add anything to your paper on methods. In any case, I will relay your message to Elizabeth and Arthur this afternoon.
  Take care!

[rabernat]

I would just like to comment that any timelines / deadlines here are completely self-imposed. While moving fast is generally good, it's worth considering whether our self-imposed deadlines best serve the interests of the CPT.

My understanding is as follows:

• @jakesteinberg is nearly ready to submit a paper on our work applying filtering with along-track SSH
• @iangrooms wants that paper to cite a preprint of the methods paper, so that the beautiful details of his filtering scheme are not buried in Jake's appendix
• This dependency means we must also rush to submit a draft of the methods paper
• And so we don't have time to work on the python package right now; instead it will be done as a separate JOSS paper

Some reasons to rush to get the papers submitted now are:

• We are worried about being scooped
• We have an externally imposed deadline (e.g. for an annual report, someone's job application / promotion dossier, etc.)

I am not actually aware of either of those two conditions being met. Is anyone else? If not, should we consider simply slowing things down by a month or two? That might resolve many of the issues raised in this discussion.

[sylviacole]

I suspect Jake's paper will not be submitted for several weeks at the earliest (late Feb?). The only deadline with this is the self-imposed variety of 'it's done so let's submit it'. If we want to hold this a little for the filtering paper, we can probably do that.

[iangrooms]

It would be nice to wait until late February since some of us are simultaneously preparing for the upcoming CPT/OMWG meeting. It would also give people who aren't already involved a bit more time to prepare contributions.

[LaureZanna]

Thanks for the info, @sylviacole and @rabernat . If @jakesteinberg ’s paper won’t be ready until the end of Feb then we would have time to contribute our little bit to the method’s paper. Following @iangrooms' recommendation, I will open an issue to list our contribution with Arthur and Elizabeth. Thanks again.

[iangrooms]

I think we've sorted this out, and have our author list, so I'll close the issue.
Right now it's Ryan, Scott, Arthur, Ian, Nora, Gustavo, Jake, Elizabeth, and Laure.
(Alphabetical by last name just for the sake of this list; final order for the paper TBD.)