diff --git a/docs/_data/navigation.yml b/docs/_data/navigation.yml
index b3e6669..3e50347 100644
--- a/docs/_data/navigation.yml
+++ b/docs/_data/navigation.yml
@@ -50,3 +50,6 @@
- name: Make a Release
link: "/release.html"
description: Guidelines for realeases (for Maintainers).
+ - name: Update the ontology
+ link: "/decision_making.html"
+ description: Community rules for updating the ontology.
diff --git a/docs/decision_making.html b/docs/decision_making.html
new file mode 100644
index 0000000..288bd82
--- /dev/null
+++ b/docs/decision_making.html
@@ -0,0 +1,157 @@
+---
+---
+
+Change Process in PaNET
+
+
+ Revisions to PaNET can vary in scope and impact. For example, they may involve:
+
+ - Experimental aspects (e.g., adding new techniques, updating relationships between techniques).
+ - Ontology structure (e.g., file format owl vs csv, categories, annotations).
+ - Other PaNET-related topics (e.g. changing the change process).
+
+
+ The process of requesting, reviewing and approving changes is mostly identical, but slightly differs depending on the nature of the change.
+
+
+
+
+ Requesting Changes
+ Requesting Changes
+
+
+ Changes to PaNET should always include sufficient information for the PaNET members to properly evaluate them. This includes specifically the Motivation and intended Modifications.
+
+ For updates to experimental aspects, the use of the "New Term" Template is recommended, as well as the consultation of the Best Practices Document. All changes to experimental information must be supported by references from authoritative sources before they can be accepted.
+
+ Changes to the ontology structure and other topics are typically requested by members of the PaNET maintenance team.
+
+ References (Experimental Changes only)
+
+
+ These sources include:
+
+ -
+ Highest Level of Authority: Publications from national and international commissions, e.g.
+
+ - International Tables for Crystallography
+ - IUPAC gold book
+
+
+ -
+ High Level of Authority: Peer reviewed journal articles, e.g.
+
+ - Original research
+ - Reviews
+ - Methodological papers
+
+
+ -
+ Lower Level of Authority: Other sources, e.g.
+
+ - Technical reports
+ - Descriptions of beamlines and setups
+
+
+
+
+
+ Definitions (Experimental Changes only)
+
+
+ The definitions from different sources can either align with each other, be conflicting, or unclear. If the provided definitions are consistent with one another, the changes will be applied as described. If the definitions contradict each other or are unclear, one of the following approaches will be taken:
+
+
+ - Combine definitions (preferred option): Where possible, merge the definitions into a single, coherent version. This is the preferred solution when the definitions can be reconciled.
+ - Ignore the less credible definition: If one definition is significantly less reliable, it may be disregarded in favor of the more credible one.
+ - Create multiple entries with disambiguation: In cases where definitions are equally credible but incompatible, the term will be listed in multiple versions, each with a disambiguation note (e.g., "Term (context A)" vs. "Term (context B)").
+
+
+
+
+
+
+ Voting
+ Voting
+
+
+ A vote should be initiated 4 weeks after the issue is created. If the discussion remains active, the discussion phase may be extended by two additional weeks. If no solution has been proposed within this time, send a remainder and re-evaluate after 2 weeks. If there is still no solution, the issue should be closed due to a lack of interest.
+
+
+ Voting Options
+
+
+ The vote usually includes the following options:
+
+ - Positive: agreeing with proposed changes.
+ - Negative: not agreeing with changes. To better understand the underlying concerns, please describe them clearly in a comment.
+ - Neutral: Not a clear opinion. Please vote neutral to indicate that you noticed the proposed changes, but you do not have a clear opinion (e.g. due to insufficient expertise). Note: Neutral votes help to estimate how many people have reviewed the proposed changes. While three positive votes from fifteen may not indicate a strong support, three positive votes alongside five neutral ones suggest broader consideration.
+
+
+
+ Voting Location
+
+
+ Voting can take place during a PaNET meeting, via an issue in the repository or a combination of both. A vote is announced by email to the PaNET maintenance team. The result of the meeting vote will be summarized in the corresponding issue. The online vote will remain open for one week, with the option to extend it by an additional week if insufficient votes are received.
+
+
+ Eligible Voters
+
+
+ All active members of the PaNET Maintenance Team are allowed to vote.
+
+
+
+
+
+ Evaluating
+ Evaluating
+
+
+ A member of the PaNET Maintenance Team will verify whether consensus has been reached based on all of the following criteria:
+
+ - No blocking concerns: No team member raises a show-stopping issue (e.g., "This breaks backward compatibility").
+ - Mitigated risks: Known risks are documented and accepted (e.g., "This may slow down the API by 5%").
+ - Unanimous agreement: If at least 50% of the active PaNET members have voted (during a meeting or online) and the simple majority supports the change, the modifications can be implemented immediately.
+
+
+ If consensus is reached:
+
+ - The maintainer adds a comment:
Consensus reached after two weeks of inactivity. No blocking concerns remain. Preparing merge requests for implementation.
+ - A merge request is prepared.
+ - The subsequent review only needs to consider changes to the structure of the ontology, if involved. The experimental aspects are already covered.
+
+
+ If no consensus is reached, the discussion should be revisited, e.g. by adding new (literature) sources, and followed by a fresh vote. Again, the discussion time should be at least two weeks. In case of experimental aspects and two failed votes based on literature sources, an expert panel must be consulted. In case of structural changes and other PaNET-related topics, two failed votes shall be interpreted as an indication that the respective issue is not relevant to PaNET.
+
+
+ Expert Panel
+
+
+ The Expert Panel must represent the relevant scientific community for the topic under discussion:
+
+ - Probe-specific: must be accepted by representatives of two or more facilities using this probe. There must not be an opposing opinion.
+ - General Terms: must be accepted by one or more facilities for each probe represented in PaNET. There must not be an opposing opinion.
+
+
+ The Panel is selected by PaNET members across facilities, with eligibility extending to any scientist actively and regularly engaged in the topic. Meetings may be held in person or online, and discussion notes will be documented within the corresponding issue. Since expertise varies by domain, the composition of the Expert Panel may differ depending on the specific focus of each discussion.
+
+
+
+
+
+ PaNET Maintenance Team
+ PaNET Maintenance Team
+
+
+ If you want to contribute regularly to the development of PaNET, join our Maintenance Team by joining the mailing list. The mailing list is used for invitations to our regular meetings including the meeting agenda and “homework”.
+ We consider members to be contributors if they did at least one of the following things within the past 12 months // since last major release by:
+
+ - Commenting on or creating an issue
+ - Creating a pull request or authoring a commit
+ - Regularly participating in meetings
+
+ Contributors are listed in the PaNET_metadata.ttl.
+ During the PaNET meetings, a contributor can ask for permission levels “write” and “maintain” in the repository in order to approve merge requests and merge branches.
+
+