Supplementary Checklists

Supplementary Checklists

⚠: Checklists are not meant to be a workflow description.

They are rather a help for those who know how to do things, but want to make sure that they don't miss anything.
(Pilots know how to fly their plane, but they still use checklists all the time)

For complete workflow-descriptions, see 🏷TODO/ADD_LINK

... for working on the project

PR from developer perspective

For detailed description, see extensive workflow

• obtain PR number via draft

• provide PR information

  • meaningful title

  • summarizing description

  • referenced issues (remember closes #IssueNumber)

• add labels

• update CHANGELOG.md

• include term-tracker for

  • new classes

  • updated classes

• commit all changes incl. term-tracker + CHANGELOG.md

• ask for review from dedicated expert

For changes in ...	... there should be a review by ...
ontology content ( [A__] / [__C])	the persons involved in discussing the issue
ontology structure ([_B_] )	the persons involved in discussing the issue
both, ontology content and structure ([AB_] / [_BC])	the persons involved in discussing the issue

... for changing the ontology

Each checklist is classified according to issue labels (see 🏷TODO/ADD_LINK):

• [A__] = new term
• [_B_] = restructure
• [__C] = definition update

In case that an ontology change touches multiple areas, the classes can be combined e.g. [AB_]

[ABC] Introducing parent classes

Tags: #subclassof #superclass #parent #children #restructure

• create parent class

  • add label

  • add definition

  • add term-tracker

• update subclasses

  • move under parent class

  • update definition

  • append new term-tracker

• test ontology