Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
adam2392 opened this issue Apr 17, 2023 · 3 comments

Comments

@adam2392
Copy link
Member

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
Copy link
Member

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

@larsoner
Copy link
Member

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

@drammock
Copy link
Member

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants