🚧 This section is still in active development and is subject to changes 🚧

This website has information and details that might be interesting to those who want to learn more about the Seedcase Project, about formal research data engineering and research software engineering, as well as better practices in data management, open science, and reproducible research.

We share posts of experiences in Posts, there are contributing guides, a roadmap of the project, and content for our outreach activities.

Seedcase Project components

Below we hope to give a bigger picture overview of the different components that make up the Seedcase Project. The aim here is to provide a better understanding of all the projects as well as the reasons we have them.

Project components that make up the Seedcase Project.

While the core of the Seedcase Project is the “Software” itself, it also depends on the proper functioning of additional components. Seedcase Software relies on the two foundation layers, which are the “Documentation” about the Software and its use as well as the “Culture and Collaboration” that enables both Documentation and Software to be developed. Supporting all these layers are the support structures that tell “How” and “Why” things are done.


The Software only exists because of the two bottom layers and the supports. More details about each Seedcase software product are found in their own GitHub repository. See the Roadmap for a list the Seedcase software.


This component contains multiple sub-components, related to the overall project, to user-friendly usage documents, and to technical details about the software itself.

For the project itself, those are found across several website:

  • Main Seedcase Project site. This includes the contacts, history of the project, governance, mission, and the purpose.
  • Community site (this site). This includes content we want to share with the community, how people can get involved or participate, as well as guides on how to do things.
  • Design documentation. This includes documents that describe the design and architecture, such as the programmatic pathways between user input to the backend of the infrastructure.
  • Team-specific documentation. This contains documents that we as a team use, such as onboarding, specifics of workflows, project management, etc.
  • Decision records. This contains records for decisions we’ve made and why we’ve made them.

Culture and collaboration

The component forms the foundation of the entire project. Without this, none of the other components can exist. There are two sub-components: the informal and formal.

Culture in general is something that is organic and develops on its own. It can be difficult to document or make explicit. Depending on the specific social dynamics of the team, of internal collaborators, and of external contributors, culture can change quite a bit. Much of these dynamics might happen through other channels like in-person activities, issue discussions, or on online communication platforms like Discord. However, a healthy culture requires some self-awareness, self-reflection, and ultimately some self-regulation to remain healthy.

The formal sub-component of culture and collaboration mostly deals with logistical and organizational aspects, like where and how often we meet (virtually), how we do meetings, how we coordinate work tasks and milestones, what expectations there are for working together (for instance during co-working sessions), and how we do work. There is some back-and-forth between this component and the Support component, with the Support component informing on, and then being refined by, how the culture should be and how we collaborate.

The informal sub-component is almost entirely about the spontaneous social dynamics and interactions, but also can be about things people might learn about or think might be interesting to share with others. For things we want to share, we aim to share them in the Community Posts section. This will be things like sharing new tools, knowledge gained from a course or conference, or other things that might come up.

Depending on what gets written in these documents, we might convert them into something more official, like publishing in an outlet.

“Why” support

This component contains explanations and justifications for why we choose the technologies, workflows, and designs that we do. This is not just for the Software itself, but also for the Documentation, Culture and Collaboration. Files and content related to this support block are found in the Decisions site.

“How” support

This component is the more technical aspects of how this project is managed, which includes most of this Community website, as well as the Teams site.