mne-tools / mne-connectivity

Connectivity algorithms that leverage the MNE-Python API.
https://mne.tools/mne-connectivity/dev/index.html
BSD 3-Clause "New" or "Revised" License
68 stars 34 forks source link

How do we have a preprint associated with mne-connectivity that encourages long-term contributions #136

Open adam2392 opened 1 year ago

adam2392 commented 1 year ago

Hi,

I've been thinking recently about the issue of getting a citable preprint for mne-connectivity.

Summary of current issues

As of the writing of this, we note that there are 28 open issues and 7 pending pull requests on Github. There are 27 total forks, and 44 stars with 18 public packages that have an explicit dependence on mne-connectivity. Some of which are just forks from contributors btw.

I'm kind of in this phase of my life and career, where I have less and less time to dedicate to this package, but I also am invested to seeing this continue to grow (albeit slowly). So I see i) maintainence and ii) decentralized improvements as core problems that we need solving. I think there needs to be some explicit incentive perhaps to encourage more ppl to contribute/etc.? I'm also trying to think of a fair way to give credit long-term.

I was wondering if a preprint (that is not published in a journal) is a good idea?

Summary of a possible solution - continuous preprint model

I wanted to raise the idea of having a short preprint that i) documents the design of MNE-connectivity and some implementation details, ii) provides a citable paper that isn't just a GitHub citation and iii) encourages researchers to make substantial contributions. The hope is that the paper educates users and future maintainers, and becomes citable and people notice and also is not officially published in a journal, so people see that they can be arbitrarily added to the arxiv preprint in future versions; i.e. preprints are not fixed to a version and can have infinite iterations that add new authors and features. This basically acts as an incentive for researchers to contribute.

If this is implemented, then there needs to be some policy in place that dictates when new authors are added to the preprint. Ideally, this policy should be designed with the maintainence of the package in mind.

Why not just publish in JOSS: I see this as a con honestly when it comes to scientific software recently. As soon as you publish something, the incentive structure entirely rewards the authors on that paper. And maybe the authors are dedicated to maintaining that piece of software, or improving it, but also what if they aren't? Even if new community members contribute, there is no recognition beyond having developer rights. This basically doesn't reward researchers at all. Eventually, I feel like researchers just ask "what's the point of contributing my free work if someone else essentially gets all the credit".

In general, there is no common way I see it done in other packages, so I feel like this is slightly uncharted territories.

Alternatives

An alternative to this is just relying on the Github citation link. Currently tho, we don't have a good policy for when to add people. Are people added with a typo fix? Are they added for implementing an algorithm, but not committed to maintaining it? Should we create a policy?

Does anyone have any experience with this workflow in scientific software? Or opinions :)? cc: @agramfort @larsoner @britta-wstnr @drammock.

larsoner commented 1 year ago

cc @hoechenberger has maybe also thought about this recently because we have considered a MNE-BIDS-Pipeline paper, too

larsoner commented 1 year ago

... and I think we can/should discuss at the dev meeting this Friday

drammock commented 1 year ago

summarizing the results of the dev meeting discussion: a few folks expressed opinions that a preprint with evolving author list is not guaranteed (or even likely) to solve this problem. For now our efforts will focus on (1) making contribution as easy as possible (alongside similar efforts in MNE-Python); (2) trying to get a few MNE-Python core devs to spend a bit more time to the connectivity repo; (3) long-term strategy of recruitment (again alongside similar effort in MNE-Python)