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.
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?
Sadly, I can’t make this time but I think one of the other coordinators for the project I work on (Astropy) will be there, so hopefully these can still be discussed.
For some context, our project has a relatively loose model. I.e., some basic guidelines like “must have tests” and “must have docs”, but otherwise it’s generally distributed to various maintainers/reviewers to follow code guidelines and strategize about sub-packages in the project. But software engineers from large teams in our field tend to be used to a more “tight” model, and we would expect a somewhat tighter model as well for anyone we might hire from Project-specific funds. With that in mind:
How can a generally “loose” governance model be integrated with team members who are more used to (or have to follow) a “tight” model?
Are there any suggestions/guidelines for how to build a formal governance model (i.e. for reporting to funding agencies easily), but without losing the “anyone can join in”/“we’re all in this together” spirit that is characteristic of a “loose” governance approach to open development?