Maintainer/Steering credit on BEP papers

[effigies]

When BEPs result in papers, there's some question as to how to provide credit to the BIDS community beyond the contributors to the BEP. The BIDS steering group and maintainers group do important work that enables BEPs, at times including direct contributions to the BEP effort. However, having a list of 6+ (currently 9) mandatory co-authors might be a bit excessive.

We propose the following convention: Each paper should have a member of the maintainers and steering group on it. By default, this should be the lead maintainer (currently @sappelhoff) and the steering group chair (currently @guiomar). If another member of either group takes a significant lead in landing the BEP, then that member would become the representative author for the group. If multiple members of either group put in a significant effort, then the number can be increased.

No particular threshold is proposed for "significant effort" or "significant lead".

If there are no objections, this could go in DECISIONMAKING.md or any other document where it seems appropriate.

cc @bids-standard/steering @bids-standard/bep_leads

[yarikoptic]

Some publication venues (and pubmed) support collective author entity grouping multiple lesser contributors into a single entity. Eg see scipy paper https://www.nature.com/articles/s41592-019-0686-2 with SciPy 1.0 Contributors . So there could be similar BIDS Steering Group which could include everyone who actively participated in steering the BEP through its life time

[effigies]

I would support using a collective entity for each of the steering group and maintainers group, when the venue permits.

[guiomar]

Thanks Chris! I also think having a collective entity for the steering group and the maintainers group would be a very good idea.

[francopestilli]

@yarikoptic @effigies I agree this is a good recent trend. I personally do like papers with hundreds of authors' names in the appendix instead of simply a branded name to a group (SicPic 1.0 Contributors or DIPY contributors). In the short term, it is possible to track down the group of individuals that that brand refers to. Yet, in the longer term, it becomes almost impossible to reconstruct who contributed to that paper because the actual name is not associated with the paper. So, in the long term, only a few names in the paper get credit. I think this is a solution that works better for the editors/journals (limiting the number of pages) than for the authors/contributors. Physics projects continue with hundreds of names in the appendix, that is because it is understood that those names actually contributed and should be published with the description of the work.

My two cents!

[guiomar]

Also agree with this.

[yarikoptic]

@francopestilli " in the appendix instead of simply a branded name to a group (SicPic 1.0 Contributors or DIPY contributors)."

appendix is not indexed etc, so even worse than "Acknowledgement" section within paper for acknowledging reciprocal contribution to the "works". A Collective name becomes a part of the bibliographic record, discoverable and indexed. I have discovered about my inclusion on scipy paper IIRC on pubmed, while establishing COI list for NSF using @poldrack 's IIRC script (had to tune it... yet to share my changes, heh heh)

[oesteban]

I would say, @francopestilli, that the problem there is that collective entities have the responsibility of maintaining the index of collaborators up-to-date, and possibly versioned by date so that you could always find out the individuals covered by that blanket.

That means, and I agree with Franco here, that having a collective entity should come with some effort in maintaining such an index. Nonetheless, I agree with Yarik's proposal and I'd move towards the collective entity.

[CPernet]

agree with collective -- but we need to push on publishers then ; i got screwed by HBM when publishing the Open Brain Consent paper despite asking many times, and @Remi-Gau is getting the same problem with neuron and the BrainHack paper

[francopestilli]

@yarikoptic I wonder whether this
"I would say, @francopestilli, that the problem there is that collective entities have the responsibility of maintaining the index of collaborators up-to-date, and possibly versioned by date so that you could always find out the individuals covered by that blanket." that @oesteban wrote could be handled by a datalad repository for BIDS that links the contributor list by a version with the article. Perhaps we could have a dedicated repo for BIDS with names of contributors (as metadata) and the article associated (as data)?

[francopestilli]

@CPernet @Remi-Gau can you elaborate? What happened to you guys? We could think of ways to avoid issues like these if you could explain.

[Remi-Gau]

So you can have consortium authorship where each member is indexed on pubmed.
And see the "Collaborator Names" heading on this page: https://www.nlm.nih.gov/bsd/policy/authorship.html

In our case the listing was close to all the other authors on the preprint: https://psyarxiv.com/rytjq/

Other possibilities include the supplementary, see this example: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3785128/pdf/emss-53122.pdf

The problem we had when we got the proof is that the consortium authors did not appear in the paper anymore: so I am fixing that now with the journal.

So it does require some extra vigilance and some additional work.

Does that help?

[yarikoptic]

Re managing contributors and collective entities, in such a way that we have a way to version and provide adequate inclusion, and echoing @oesteban and @francopestilli 's ideas:

• indeed I think having a git repo with versioned releases could be a mechanism to use
  • I do not think that any DataLad "magic" is really needed, so could be a pure git
  • I think it might as well be this repository!
• We need a helper to manage contributors listing + minting (upon versioned release) all desired listings
  • https://github.com/bids-standard/bids-specification/blob/master/src/99-appendices/01-contributors.md provides a good "cumulative" starting point
  • all-contributors could be used, as e.g. we use in https://github.com/con/open-brain-consent/#contributors- as a more "formalized" and automated data collection/structure
  • we would need to extend on .all-contributorsrc to not only list "contributions" (as "infra", "code", etc) but extend with
    • committees (e.g. "steering-committee") and BEPs (e.g. "bep032")
  • have helper tool(s) to produce
    • necessary listings for any needed "version" or "range of versions":
      • e.g. if bep032 started from version1 (or date1) and was merged within version2 (or date2), to compose "steering-committee" listing for that duration we take union of all "steering-committee" members in (version1, version2] range.
    • records in any other "standard" format, e.g. for zenodo
    • edit1: would be cool if tooling would automagically sync with https://github.com/orgs/bids-standard/teams - one way or another: e.g. we could make it adjust the record if teams are edited - new people added/removed.
    • edit 2: upon next version release, tool could refresh the listing of "contributions" to reflect the "diff" from prior version
      • cummulative listing could still be computed but also reflecting specific version authors/contributions
  • Exactly for such a purpose of "centralized" contributors management and conversion, @vsoch (with nagging from yours truly) awhile back developed https://github.com/con/tributors/ . Unfortunately we have not really "finalized it" to degree of it being as turnkey as all-contributors is, but I think necessary tool-ing could be developed there to support needed here use-cases: it already has good amount of relevant functionality which could be of assistance: establishling linkage between github accounts and orcid records, etc .
    • edit 3: our tributors workflow got fixed today in datalad, and we received this nice PR: https://github.com/datalad/datalad/pull/5618/files . Automation rules!

So overall: we need to formalize list of contributors, extend with listing for committees and BEPs, keep everything in a repo (possibly right here), and code up additional tooling. But overall -- it is very much doable and would be really nice in the long run IMHO!

[francopestilli]

@yarikoptic good proposal. A bit decentralized :-)
Will it be easy enough to manage once in place?

[yarikoptic]

well, everything is in "our hands" in that someone yet to make it happen -- so it could be as easy as those hands would make it ;-)

edit: as for "decentralized" -- it is the nature here. We already have decentralization (contributors doc, git commits, teams) but without synchronization. The idea is to have a tech to keep it in sync.

[Remi-Gau]

I had not realized that this issue until I got pinged and so now I feel I need to update on the some of the internal discussion amongst BIDS maintainers and the steering group.

Regarding crediting BIDS maintainers (only so this does not cover contributors), we are going into the direction of the consortium authorship as mentioned above (that is indexed in pubmed, google scholar): #627 (comment)

Briefly, all maintainers would be included in this consortium by default but they can also be included as a "regular" author, with their names appearing along side other authors of the paper. To decide whether they qualify but a "regular" authors, we'll try to get some inspiration from the ICMJE criteria:
http://www.icmje.org/recommendations/browse/roles-and-responsibilities/defining-the-role-of-authors-and-contributors.html

There is no formal document describing this yet though (very much WIP).

But I suspect that this could maybe give some inspiration to how to credit contributors too. And I suspect that the 2 should be coordinated to a certain extend.