Skip to content
Open
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
58 changes: 34 additions & 24 deletions GOVERNANCE.md
Original file line number Diff line number Diff line change
@@ -1,59 +1,65 @@
# Governance of the Research Software Ecosystem (RSEc)

The Research Software Ecosystem (RSEc) aims to act as a resource for collecting, maintaining, sharing, and preserving high-quality information (“metadata”) about research software across scientific applications, building upon the ELIXIR’s work in life sciences.

Research software is a critical component of nowadays data-driven research. Thus, being able to discover, understand and adequately utilize software is essential. Associated metadata to research software enables discovering, understanding and utilizing software. However, metadata tends to be sparse and frequently inconsistent across different resources. The RSEc aims to act as a proxy to maintain and preserve high-quality metadata for describing research software. To make this possible, the RSEc needs to work closely together with heterogeneous metadata resources, often with different objectives, users communities and technical implementations, to bring metadata together, facilitate integration, curation, and re-usability by the contributors and anyone willing to consume the metadata produced in this context.
The RSEc currently focuses mainly on the platforms associated to the ELIXIR Tools platform that gather, curate, maintain and consume high-quality metadata associated to research software. Specifically, this ecosystem includes bio.tools, Biocontainers, OpenEBench and WorkflowHub as platforms, and EDAM as the chosen ontology for describing research software metadata. While each contributing platform has its governance model, the aim is to establish a governance model to facilitate the interactions among those systems, enable the inclusion of new contributors within ELIXIR and collaborators beyond ELIXIR, set roles and responsibilities and establish the overall decision making process.

# Overview/Scope
Research software is a critical component of modern data-driven research. Thus, being able to discover, understand and adequately utilize software is essential. Associated metadata software enables discovering, understanding and effective reuse of research software. However, such metadata is often sparse and inconsistent across different resources. The RSEc aims to act as a proxy to maintain and preserve high-quality metadata for describing research software. To make this possible, the RSEc needs to work closely together with heterogeneous metadata resources, often with different objectives, users communities and technical implementations, to bring metadata together, facilitate integration, curation, and re-usability by the contributors and anyone willing to consume the metadata produced in this context.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd have this paragraph switched with the previous one, it reads more like an introduction than the one before.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In principle, yes. I was thinking though more about the typical .md rendering - and that the first paragraph acts more like an abstract for the otherwise not-short document.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me know what you think - I'll hold off with the merge until then.


The RSEc currently focuses mainly on the platforms associated to the ELIXIR Tools platform that gather, curate, maintain and consume high-quality metadata associated to research software. Specifically, this ecosystem includes bio.tools, Biocontainers, OpenEBench and WorkflowHub as platforms, and EDAM as the chosen ontology for describing research software metadata. While each contributing platform has its governance model, the aim is to establish a governance model to facilitate the interactions among those systems, enable the inclusion of new contributors within ELIXIR and collaborators beyond ELIXIR, set roles and responsibilities and establish the overall decision making process.
## Overview/Scope

As an open source project bringing together under the same umbrella different projects and initiatives, the RSEc follows the guidelines, recommendations and standards put forward by ELIXIR, and other communities driven initiatives in the framework of the Open Science efforts.
This document defines the governance model, roles, responsibilities, and ecision-making processes of the Research Software Ecosystem (RSEc). As an open source initiative bringing together under the same umbrella different projects and initiatives, the RSEc follows the guidelines, recommendations and standards put forward by ELIXIR, and other communities driven initiatives in the framework of the Open Science efforts.

# Roles And Responsibilities within the Research Software Ecosystem (RSEc)
## Roles And Responsibilities within the RSEc

This section lists a number of categories of roles and users for the tools ecosystem. All users and contributors are subject to the code of conduct specified and available in the RSEc main repository and website.

## Users
### Users

Users are anyone who has a need for the RSEc. For instance, a user can be a researcher looking for information about a specific software, or a software specialist analyzing aggregated metadata about software. These data are distributed under open licenses specific to each source.
Users are individuals or organizations who make use of the RSEc. For instance, a user can be a researcher looking for information about a specific software, or a software specialist analyzing aggregated metadata about software. Metadata is distributed under open licenses specific to each source.

## Contributors
### Contributors

Contributors are community members who help maintain and develop the RSEc. Any person can contribute. There is no expectation of commitment to the project, no specific skill requirements and no selection process.
Contributions can take multiple forms such as reporting bugs, writing documentation, contributing code (e.g. metadata processing pipelines), or providing and maintaining new metadata sources. Any form of contribution is welcome, and we will recognize all of them.

## Committers
### Committers

Committers are contributors who have demonstrated their ability and will to maintain and develop the RSEc. Committership allows contributors to merge contribution requests and make changes directly to the metadata and code repositories. All these actions however have to follow the contribution and decision processes outlined in Organizations.md document..l
Committers are contributors who have demonstrated their ability and will to maintain and develop the RSEc. Committership allows contributors to merge contribution requests and make changes directly to the metadata and code repositories, and is granted based on sustained, high-quality contributions and community trust. All such actions however have to follow the [code of conduct document](CODE_OF_CONDUCT.md).

## Operations Committee (OC)
### Operations Committee

The Operations Committee will be assembled from all Contributors. We explicitly and strongly encourage members of contributing communities to join the RSEc by proposing new members to this committee. OC members are expected to participate in technical meetings, monitor the project user support, its development and evolve the project together with the SC.
The Operations Committee (OC) is composed of Contributors who actively participate in the technical operation and evolution of the RSEc. + Membership in the OC is open and voluntary, and may change over time as participation evolves.
We explicitly and strongly encourage members of contributing communities to join the RSEc by proposing new members to this committee. OC members are expected to participate in technical meetings, contribute to user support, monitor project development and evolve the project in coordination with the SC.

## Strategic Committee (SC)
### Strategic Committee

The Strategic Committee monitors the project, making sure it reaches its goals successfully and that the project resources are sufficient to ensure this success. Evolutions in the goals and structure of the project are controlled by the SC, and any proposed change in the governance model of the project should be approved by this committee. The SC is formed by:
The Strategic Committee (SC) provides strategic oversight, ensuring that the project meets its objectives and has sufficient resources to do so. Changes to the goals, scope, or structure of the project are overseen by the SC, and any proposed change in the governance model of the project should be approved by this committee. SC members are expected to act in the best interest of the overall ecosystem, rather than representing individual platforms exclusively.

- The 3 excos from the ELIXIR Tools Platform,
The SC is formed by:
- The 3 ExCos from the ELIXIR Tools Platform,
- 3 representatives from the OC,
- 1 representative from the ELIXIR Hub, who will act as a facilitator.

## SC Chair
### Strategic Committee Chair

The SC Chair is a single individual, member of the SC, and elected for a 2 year non-renewable term by the SC, with the expectation that this role should rotate between its members. The Chair has no additional authority over other members of the PMC: the role is one of coordinator. The Chair is also expected to ensure that all governance processes are adhered to, and has the casting vote when the project fails to reach consensus.
The SC Chair is a single individual, member of the SC, and elected for a 2 year non-renewable term by the SC, with the expectation that this role should rotate between its members.

# Communication channels
The Chair has no additional authority over other members of the SC: the role is one of coordinator. The Chair is also expected to ensure that all governance processes are adhered to, and holds a casting vote only when consensus cannot be reached after reasonable discussion.

## Communication channels

The official communication channels for user support and project discussions in general are:

- The official contact email, tools-ecosystem@elixir-europe.org, which goes to all members of the OC
- The Gitter messaging system channel for the ecosystem: https://gitter.im/bio-tools/ecosystem
- The issue tracker of the RSEc repository

# Support
## Support

All participants in the community are encouraged to provide support for new users and contributors. This support is part of the RSEc, and is provided as a way to encourage reuse and contributions to the service. Support is provided on the communication channels listed in the previous section.

# Contribution Process and credit
## Contribution Process and credit

Anyone can contribute to the project, regardless of their skills, as there are many ways to contribute. The gitter channel is the most appropriate place for a contributor to ask for help when making their first contribution.
Contributions can take multiple forms, such as:
Expand All @@ -64,13 +70,17 @@ Contributions can take multiple forms, such as:

The various ways of contributing are described in more detail in a separate document.

The RSEc wants to acknowledge all forms of contributions. An exhaustive list of contributors is maintained in a dedicated file of the main repository
The RSEc wants to acknowledge all forms of contributions. An exhaustive list of contributors is maintained in [a dedicated file of the main repository](https://github.com/research-software-ecosystem/research-software-ecosystem.github.io/blob/main/_data/CONTRIBUTORS.yml).

# Decision Making Process
## Decision Making Process

Apart from decisions which are part of the daily operations of the RSEc, two major categories of decisions will be taken:

- Simple decisions, such as the inclusion of a new metadata source within the scope, will be subject to simple majority within the OC.
- Major decisions that can modify the scope and goals of the project, or affect its resources, or modify the governance of the project, should be taken and approved unanimously by the SC.
- Major decisions that can modify the scope and goals of the project, or affect its resources, or modify the governance of the project, should be taken and approved unanimously by the SC. All major decisions must be documented and publicly recorded in the project repository.

## Acknowledgements

_Many parts of this document, especially the Roles and responsabilities section, have been heavily inspired by existing governance documents, such as http://oss-watch.ac.uk/resources/meritocraticgovernancemodel and https://hedgedoc.softwareheritage.org/codemeta-governance?both#_
Parts of this document, especially the Roles and responsibilities section, have been heavily inspired by existing governance documents:
- [OSS Watch Meritocratic Governance Model](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
- [Software Heritage Codemeta Governance](https://hedgedoc.softwareheritage.org/codemeta-governance?both#)