Write a comment

previous note: this is not a complete review, but it is a summary of my main comments about the paper.

Major point:

There are a lot of very important things in the paper, I indeed already cite this preprint in some grant application as a roadmap for community building and collaboration toolbox choice. However, I think the paper is too long and contain two quite different elements : the maturity model (table 1, how to build a community, what is to be done), and information about RCM as a career (what skills are needed, how could this be professionalised and institutionalised). While the second part builds on the first, I think the maturity model would deserve its own paper, with much more information about how it was drafted, examples of development and how to use it, maybe with a section on online and offline tools that may be used at different levels. Indeed the paper is really long and splitting the topics in two papers may make the work of the readers easier, and allow the authors to best fit their story telling to specific target groups (I would think community builder for the maturity model, institutions and administrative personal for the RDM professionalisation ?).

In short, I would recommend shortening the paper and/or splitting the content in several paper. The main messages of the papers are very important and I would guess it would touch a larger audience if the paper would be shorter and maybe more punchy.

Minor points:

There are some parts of the paper that are directed toward data science (and AI), while the main part talks about multi-disciplinary “research communities” , and the main example of community is the turing way, which is writing a book. Is the paper about RCM in any context, or only in the context of “open-research-community-management.” as the github repo name suggests ?

I find part 2.3 is a bit weak, because the relation between community building and data science or open science is not as straightforward as that section suggests. The RCM work is intrinsically social (as stated in section 4.2.2) but that section present them as open science heros with huge knowledge in data science, version control and other very technical knowledge.   Section 2.3.4 is made particularly weak by restricting the discourse to AI: EDIA principles are important for any project, not only for AI related ones, as this paragraph suggests.

Interestingly for this question would be the UK’s BridgeAI program project. I take for granted, this has little to do with open science or RRI (?). Interesting would be to see how the knowledge/processes from the other project was adapted here.

For section 3.2, it is not always clear what the term “team” is directed to (team in one of the project of table 1, team of RCM ?)

Competing interests

I have worked with the authors inside the turing way community.