Proposal for basic Bioregstry governance policies

[cthoyt]

The goal of the Bioregistry is to enable community-driven curation and maintenance of a registry of prefixes and their associated metadata. This is a first suggestion for some minimal goveranance (heavily inspired by https://github.com/mapping-commons/SSSOM/issues/82, since that is a similar community-driven effort):

Manually Updating the Bioregistry

• Manual updates to the contents of the Bioregistry (e.g., adding a new prefix, merging prefixes, splitting prefixes, or updating a prefix's associated metadata) should be done either in the form of an issue or a pull request.
• Manual updates can be accepted if all continuous integration tests pass (TODO link to document explaining what are the rules for this) and a member of the Review Team approves. It's best practice that a member of the Review Team does not approve their own updates.
• New prefixes must conform to #158 and #133
• Attribution information for the requester and reviewer of manual updates should be collected in the form of an ORCiD identifier.

Review Team

The review team is responsible for reviewing requests for new prefixes, merging prefixes, splitting prefixes, and updating metadata associated with prefixes. It is implemented as a GitHub team that has "triage" permissions (e.g., able to maintain issues and pull requests).

Until all of the potential update interactions have been codified with GitHub actions workflows, the review team is also responsible for either helping the requester create an appropriate pull request or creating an appropriate pull request directly if none has been given by the requester.

Membership

• Membership to the Bioregistry Review Team is requested on the issue tracker
• Membership to the Bioregistry Review Team is granted at the discretion of the existing Bioregistry Review Team using Disapproval Voting

Core Development Team

The Core Development Team is responsible for maintaining the codebase associated with the Bioregistry, which includes the Python package, the Bioregistry web application, docker configurations/artifacts, and related GitHub repositories. It is implemented as a GitHub team that has "maintain" permissions (e.g., able to write to the repo as well as maintain issues and pull requests).

Contributions to the Bioregistry code should be submitted as pull requests to https://github.com/biopragmatics/bioregistry. They should conform to the contribution guidelines. Code contributions must be approved by a member of the Core Development Team as well as pass continuous integration tests before merging.

Membership

• Membership to the Bioregistry Core Development Team is requested on the issue tracker
• It is required that a potential member of the Bioregistry Core Development Team has previously made a contribution as an external contributor (to which there are no requirements)
• Membership to the Bioregistry Core Development Team is granted at the discretion of the existing Bioregistry Core Development Team using Disapproval Voting

Publications / Attribution

• All members of the core development and review teams are automatically authors on Bioregistry papers and can propose other co-authors
• Larger external institutional contributors should be acknowledged on the repository's main README.md as well as on https://bioregistry.io

[bgyori]

This looks good! The section

Because the code is already set up in https://github.com/biopragmatics/bioregistry and https://github.com/biopragmatics/bioregistry-docker, external contributions are welcome. These should must be approved by a member of the Core Team as well as pass continuous integration tests before merge.

is a bit strangely worded, it could say something like

Contributions to the Bioregistry code should be submitted as pull requests to https://github.com/biopragmatics/bioregistry. Code contribution guidelines are available at [...]. Code contributions must be approved by a member of the Core Team as well as pass continuous integration tests before merging.

we could then add a standard code contributions guideline in a separate file explaining the fork/pull request policy, code style, etc.

[cthoyt]

@bgyori I've started a PR for a code contribution file in #162 as well as tagged you on #161 to discuss adding a code of conduct

[mellybelly]

Few suggestions:

easy:

• [x] use ORCiD for attribution (added ORCiD field to all requests in 990d570, added reviewer ORCiD field in 94eca0a)
• [x] You may also wish to have example block attribution/acknowledgements information; this really helps people do the right thing. here is an example: https://covid.cd2h.org/acknowledgements (Done in fdd7608 and d1d3db7. See this section of the README)
• [x] Consider calling it "Core Development team" to distinguish from Review team

harder: One of the biggest governance challenges is deciding who gets to decide, and what their term limits/process for staying are on any given committee or decisionmaking body. How can we ensure that its not one person and their friends? or that the members are diverse in multiple ways? Maybe a statement to this effect is sufficient for now:

To instantiate the two committees, volunteers will be accepted by nomination (self or otherwise) to @cthoyt. Once a critical mass of nominees is identified (e.g. 3-5 for each group), a review of the members to ensure diversity (institutional, expertise, demographics, etc.) will be conducted, with additional members sought if needed. The groups will define their SOPs for review and development and these will be posted publicly. We will also determine a strategy for turnover of the committees.

[cthoyt]

I recently began committing this in https://github.com/biopragmatics/bioregistry/blob/main/GOVERNANCE.md, there's also some information about when the governance gets bootstrapped. Not exactly what @mellybelly had in mind, but I recruited @megbalk, @callahantiff, and @lubianat to join as the initial team to have a wide variety of interests, backgrounds, and a specific focus on getting highly available early career scientists involved