[DISCUSSION] acknowledge contributors in DOIed specs on Zenodo

[tyarkoni]

To facilitate citation, we should auto-generate Zenodo DOIs for each spec, with author list extracted from the contributors list in the docs.

---

edit by @sappelhoff 2020-05-06: PDF versions of the BIDS spec are now stored on zenodo: https://zenodo.org/record/3720628 ... we still have to adjust the metadata on Zenodo to properly acknowledge contributors.

[chrisgorgo]

What authorship order would you suggest?

[tyarkoni]

Good question... we should probably weight each of the different types of contribution some specified amount, sum up each person's contributions, and then order in descending order of total score. (With the option to manually fix some people--e.g., you should always go first in the core BIDS spec, I should go first in the BIDS-Model spec, etc.).

[chrisgorgo]

We need to figure out the formula before we can continue (setting up Zenodo is fairly simple). An interesting alternative would be to randomize the list for each release...

I'm also unclear about the concept of "all specs". Historically BEPs has been merged into the main spec and maintained over there. Thus there is no "HED spec" or "MEG spec" (although MEG one has a dedicated Scientifica Data paper as the main citation). I was more envisioning the spec to have a single DOI (and extensions having dedicated papers).

[tyarkoni]

I'm not sure assigning a single DOI makes sense. The degree of modularity is already pretty high. I guess I think of BIDS-Derivatives, BIDS-Models, etc., as modular components in a broader ecosystem—much like dependencies of a package. I think maintaining a single DOI is going to make proper credit assignment very difficult in two respects: (a) when people cite the spec, we'll have essentially no idea what part of it they're making use of, and (b) it'll dilute many people's contributions (because you might have played a central role in BIDS-Derivatives, but never touched the other documents).

[chrisgorgo]

I agree with the credit argument. I guess we could use Zenodo API to issue multiple DOIs upon spec release and associate subsets of the md files with each one. Versioning would have to be the same though if we are to live in the same repo. It's more complex, but not impossible.

Please also mind that Zenodo is not indexed by Google Scholar, so I would still rely on individual papers dedicated to each BEP for credit purposes.

[tyarkoni]

Joint versioning sounds reasonable.

I think it's reasonable to assume that in the not-too-distant future, Google Scholar will index Zenodo (see openjournals/brief-ideas#132). If I read the linked thread correctly, they may already be indexing text-heavy repos, which this certainly would be.

[chrisgorgo]

Ok - could you propose a formula for authorship order? It would be a good start of the discussion.

[tyarkoni]

As a first pass, maybe just weight everything equally? We can iterate later...

[tyarkoni]

The contributions document is definitely out of date though, so maybe it's worth asking people to update it...

[tyarkoni]

I guess it's a bit weird to make authorship order a function of the number of icons in the list. It invites pretty easy gaming, and rewards people who interpret their own contributions liberally. But I guess it's fine for now, and we can change it later if it seems problematic.

[chrisgorgo]

Summoning @bids-standard/everyone for comments. Please let us know if this is ok with you.

[CPernet]

+1 authorship but yes tracking contributions matters -- icons did the job so far

[yarikoptic]

This Repo doesn't include among git contributors all who contributed to original Google doc etc... Is there a way to extend the list zenodo generates?

[chrisgorgo]

Yes - through .zenodo.json file. We will need it for affiliations and orcid anyway.

[effigies]

Fine with me. A script that reorders the .zenodo.json according to some criteria should be pretty easy to achieve. We use one for nipype releases, so I can adapt that or provide it if someone wants to play with it.

[adelavega]

I'm fine with either lead author(s) + random order, or scored order. I suppose tiebreakers are also needed. Fine with alphabetical or random in that case.

[jbpoline]

sounds good to me as well

…

On Wed, Oct 24, 2018 at 9:06 PM Alejandro de la Vega < ***@***.***> wrote: I'm fine with either lead author(s) + random order, or scored order. I suppose tiebreakers are also needed. Fine with alphabetical or random in that case. — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#66 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAQyaEik7HUgiCJf56tpxnPR8jjb4t7Iks5uoQ6BgaJpZM4X4hdD> .

[jasmainak]

I'm fine with any scheme of authorship but maybe slight preference for random order. Is there going a different zenodo doi for each version? I can imagine people contributing in ebbs and flows.

[chrisgorgo]

Yes, each release and each extension will have a separate DOI.

[nicholst]

We just have to start by accepting that it is impossible to do in a way that truly reflects effort in a fine grained way. The way we've done it on NIDM is to simply have first and last author chosen and everyone in between is alphabetical. If there are multiple people in those first and last roles does Zenodo allow "these authors jointly played the {first,last} author role"?

[sappelhoff]

+1 on having DOIs for the specs (in addition to standalone publications of BEPs like the MEG one did)

We just have to start by accepting that it is impossible to do in a way that truly reflects effort in a fine grained way.

I agree, but let's summarize our options:

Options for authorship order

1. first and last author fixed through election (possibly shared with others), the remaining authors order:
   a. randomized
   b. alphabetically
2. all authors in randomized or alphabetical order
3. counting the number of icons in each respective spec (equal weighting), tie breaks:
   a. randomized
   b. alphabetically
4. taking into account the Github contribution metrics per spec:
   a. number of issues raised
   b. number of pull requests ... and how many were merged
   c. number of lines contributed / deleted
   d. number of commits
   e. number of code reviews and comments
5. any combination of 1. to 4.

Regarding point 4., I am not sure which of these contribution metrics we will be able to easily parse from Github.

Personally, I would go with option 1.a because @nicholst comment will hold true, even given a complex combination of options 1. - 4. that I listed above. I also acknowledge @CPernet's comment above, that the order is important (> tracking contributions matters) ... however I would leave that to the standalone publications that come out of every BEP (so far for MRI (main spec) and MEG ... EEG and iEEG to come)

[teonbrooks]

I would go for first author(s) and alphabetically ordered contributors.
I don't know/understand what a last author would mean in this case.

Emoji-based ranking isn't a bad idea if we have an agreed-upon weighting but i do understand the concern about potentially gaming (could have some safeguards in CoC).

Github would be a good idea if we started the BEPs on Github from the beginning. there will be missing attribution for work done in a Google doc first when it is brought over here.

[nicholst]

I don't know/understand what a last author would mean in this case.

Whatever method we arrive at, we add a note that explains the ordering. This is essential especially if we use randomised. I think last author is not impossible to define (and, again, this can all be defined in a note). What I have witnessed in this community effort is that each sub-component typically has 1 or 2 people that are responsible for the drive and energy to bring a particular BEP to completion, these are the first authors. And then there is someone has intellectual responsibility for BIDS as a whole, who is like a cop on the beat, who ensures that a particular BEP fits within the ecosystem (e.g. doesn't conflict with core BIDS, doesn't bloat in scope)... as I understand it this is @chrisfilo, though I may have missed it if others have played this role; this seems a natural final author role. As long as we clearly articulate our decided strategy, I think it's all good.

[sappelhoff]

Github would be a good idea if we started the BEPs on Github from the beginning. there will be missing attribution for work done in a Google doc first when it is brought over here.

There is a way to get the contributions from the Google Doc version history ... at least @choldgraf and @dorahermes somehow managed to extract a list of emails for the iEEG author list. Or did you do this manually? 😲

[dorahermes]

For the BIDS-iEEG contributions @choldgraf and I have been keeping a manual list because we also got comments from people who send us emails rather than make comments on the google doc.

[jchoude]

LGTM.

[emdupre]

Is the thought to use defined first and last, and alphabetical within ? That would be my vote, personally 👍

I wonder if this question is also worth pinging to the mailing list, especially for contributors who have been active in the past but have not yet switched to GitHub.

[choldgraf]

@sappelhoff yeah this basically involved us manually going through our email history and/or looking up emails on the internet :-)

I'm +1 on defined first/last, w/ random in between, as long as the roles and requirements needed to be in those positions are clearly-defined and agreed-upon by the community. I feel like to be a first or last person on the spec DOI, you should also be expected to fulfill some duties in order to have that spot, similar to how "core team" members of open projects have to be actively involved in some particular part of the community etc.

As a point of information, what Project Jupyter does for any paper coming out of the project is to make the first author "Project Jupyter" and everybody else alphabetically listed after. It has pros and cons.

Personally, I'd be a bigger fan of making the roles within the BIDS community explicit and recognized / advertised. Something like: https://www.rust-lang.org/en-US/team.html

[mnarayan]

We just have to start by accepting that it is impossible to do in a way that truly reflects effort in a fine grained way. The way we've done it on NIDM is to simply have first and last author chosen and everyone in between is alphabetical. If there are multiple people in those first and last roles does Zenodo allow "these authors jointly played the {first,last} author role"?

I have a slight preference for suggestion from @nicholst to pick alphabetical for middle authors. But okay with other suggestions also.

[melanieganz]

I am with @nicholst regarding deciding a first and last authorship and either random or alphabetical in between. I would agree though with @choldgraf that roles and requirements needed to be in first or last author positions should be clearly-defined and agreed-upon by the community.

[KirstieJane]

+1 on first & last defined with alphabetical in the middle.

I see the benefit of random, but I think too many readers of the citation (eg on someone's CV) will not realise that the order is random and will assume it means something. Alphabetical is a) obvious to the reader and b) much more commonly used.

[Gilles86]

+1 on first & last defined with alphabetical in the middle.

I see the benefit of random, but I think too many readers of the citation (eg on someone's CV) will not realise that the order is random and will assume it means something. Alphabetical is a) obvious to the reader and b) much more commonly used.

+1

[vcalhoun]

This sounds fine to me as well. Though sometimes the 2nd first and 1st last fields can be useful if folks feel strongly about joint credit for substantial work when more than 2 are involved. VDC From: Gilles de Hollander <notifications@github.com> Sent: Friday, October 26, 2018 6:31 AM To: bids-standard/bids-specification <bids-specification@noreply.github.com> Cc: vcalhoun <vcalhoun@mrn.org>; Manual <manual@noreply.github.com> Subject: Re: [bids-standard/bids-specification] Automatically generate DOI for all specs (#66) +1 on first & last defined with alphabetical in the middle. I see the benefit of random, but I think too many readers of the citation (eg on someone's CV) will not realise that the order is random and will assume it means something. Alphabetical is a) obvious to the reader and b) much more commonly used. +1 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#66 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AO7mJBOBKirm8E-xKYiJrrXGqBC8G-OKks5uowBygaJpZM4X4hdD> .

[danlurie]

I'm happy with designated first/last (and maybe also second/penultimate if there is a need) with everyone else alphabetical in between.

In general I like the idea of credit taxonomies, and emoji are fun, but gauging contributions by how many areas a person has contributed probably isn't the best way. For example, I've contributed in a bunch of different ways (ideas, tools, support, etc) to various BIDS efforts, so I've got a bunch of icons next to my name, but there are a lot of people with fewer icons than me who have made much more significant/consistent contributions.

[effigies]

https://citation-file-format.github.io/ seems to what Zenodo is moving to over .zenodo.json snippets. (Announced here.)

[Remi-Gau]

@bids-standard/everyone

PR #1115 would in effect start implementing adding contributors to our zenodo releases of the spec.

At the moment the PR would simply list ALL contributors alphabetically (no first or last authors)

[Remi-Gau]

Note that BIDS steering group is in favor of listing all contributors in alphabetical for the zenodo release.

#1115 (comment)