What would you like to know about governance strategies for open source research software projects?

openscience
governance
community-call
community
Tags: #<Tag:0x00007f656f78e9d0> #<Tag:0x00007f656f78e890> #<Tag:0x00007f656f78e700> #<Tag:0x00007f656f78e598>

#1

Author: Dan Sholler

As a Postdoctoral Fellow with rOpenSci at UC Berkeley, I’ve been working on an ethnographic study examining governance of organizations in the open science movement. In short, I’m interested in how organizations like open source software projects get a disparate group of scientists to engage with their tools or services and the mechanisms they use to govern the actions of contributors and users. On Tuesday, December 18th, I’ll share some of my findings to date in a Community Call. I’d like to get questions and comments in advance so I can tailor the discussion to the interests of the community.

Governance refers to the processes of developing and enforcing policies and norms for a given community or organization with the aim of structuring some set of activities (in this case, software development and use). For example, if you wish to contribute a package to rOpenSci, you must go through a specific onboarding process that includes package review, revision, and agreement to a code of conduct. The onboarding process is a particular bundle of governance strategies that helps to ensure software quality and adherence to some best-practices in software development. In this call, we’ll pull back the cover on these types of management approaches and discuss how they contribute to the long-term sustainability of a software project.

Ahead of the call, I’d like to hear about some of the governance challenges you’ve experienced in contributing to or leading a project, the strategies you’ve used or observed in overcoming challenges, and any other thoughts you have about the topic. I’ve given some background and an idea of the topics I’ll cover in an announcement blog post. Please have a look and then add your questions or comments here so we can have a lively discussion on the Call.


#2

I’d be interested to hear about options how established projects can make it attractive for young PhDs / postdocs to contribute. I mean, if others have worked on a project for a few years, it gets harder for new people to significantly move the project forward with a given time investment (e.g. a week or month or year of their life). So the older and larger a codebase is, the harder it is to attract young people, and one has to somehow actively promote and reward new contributors, no?