This repository is meant to organize the work of the NFDI Section (Meta)Data Working Group Ontology harmonization and Mapping.
This repository is two things. First, it is the cloud storage space where we upload and share files with our WG members and the rest of the world in a version controlled manner. Second, it is the space in which we can discuss asynchronously and transparently the tasks we need to accomplish via GitHub Issues and Pull Requests.
- Working Group Charter published version (Zenodo) & editor version (GDoc)
The main channel of communication of the working group is the mailing list, for which you can sign up here, if you are affiliated with an NFDI consortium.
We have bi-monthly meetings according to these schedules:
- section-metadata-onto_every_2nd_wednesday_call_series.ics
- section-metadata-onto_every_4th_tuesday_call_series.ics
To contribute via this repository, members of the working group need to have a GitHub account and some basic knowledge about how to work with Git and GitHub to be able to participate. You need to know what an issue, pull request and a branch is. To open or comment on issues, a browser suffices as the main interface to interact with this repository. To upload new or edited existing files and to create branches and pull request, we recommend using the GitHub Desktop app, if you are not familiar with Git already. Please consult the web for one of the many tutorials on how to use Git, GitHub, GitHub Desktop, like the official GitHub documentation on Issues, Pull Request and Branches.
We expect the WG members to follow the activity of this repository by starring or watching it. Members who want to contribute directly must either be made part of the repository team (contact @StroemPhi), or fork the repository.
A prototypical interaction of a WG member with this repository would entail:
- checking here regularly, to see if any new open epic subtask issues have been created to be voted on,
- creating epic subtask issues,
- commenting on issues (participate in discussions),
- creating an issue branch when working on a specific subtask that requires the creation or editing of files,
- submitting changes made on an issue branch via a pull request.
The issues of this repository represent specific tasks. We use them to discuss, coordinate and work on the specific tasks of our working group. An issue is open as long as it needs to be worked on or discussed and is being closed when the task it represents is completed. An issue can be tagged with labels and assigned to one or more WG members, which allows them to be categorized, filtered and sorted. Each issue should always have a concise and self-explanatory title and description. Each issue is open to be commented on or referenced by any GitHub user, which allows us to work in an open source fashion also with people outside our working group.
There are three kinds of issues:
Epic issues represent the objectives we have identified in our WG charter. Hence, we will only create new epics, once we have agreed to amend our WG charter accordingly. These issues are called epics because they need to be broken down into smaller and more concrete sub-issues to be completed, and thus will probably remain open throughout the existence of our working group. The WG members assigned to an epic issue are expected to moderate, curate or document the discussions about the epic happening either on the epic issue itself, in associated sub-issues, pull request or emails or within our regular calls. Since all WG members are expected to contribute to each objective of our WG charter whenever possible, they are also expected to contribute in this repo in some form via the sub-issues associated with an epic issue. All epics are tagged with the label "charter epic" and a label that represents the topic they address, e.g. "Collaborating Internationally". The topic label of an epic comes from a controlled list and is being used to tag its associated sub-issues. The comment section of an epic issue should only be used for discussions about the required outcomes of an epic/objective.
Additionally, each epic may have a folder in this repository to store any files associated with it.
As the name implies, a sub-issue represents a subtask associated with an epic ( = one of our objectives). A subtask could either be a concrete action item assigned to one or more WG members, or, it could represent a discussion about a certain aspect of an expected epic outcome that the WG needs to find an agreement on before being able to formulate concrete action items. For example, we might want to first discuss in one sub-issue which types of terminologies qualify for evaluation by our WG, before we create a sub-issue that is about the evaluation of a specific terminology. The comment section of a sub-issue should only be used to discuss the particular sub-issue. Creating epic sub-issues in such a granular way allows us to focus on specific aspects separately. By linking related sub-issue to each other, we should thus get a better overview of what needs to be done and what needs to be discussed.
To open a new sub-issue or link an existing gone with an epic please use the create sub-issue button within the
description of an epic issue.
Organizational issues are those that are concerned only with "meta" discussions about how to structure our work. Hence, they should not be associated with any epic or epic subtask issue. For example, when you have questions around or problems with the use of this repository, you should be filing an organizational issue. To file a new organizational issue, please use this template, change its default title and add a meaningful description about what needs to be discussed.
There exists one permanently open, organizational issue that is pinned to the top of the issue list. This issue explains how all open epic subtask issues can be prioritized by up-voting. This is intended to to be discussed in upcoming calls.
TODO: explain how to interact with our project.