JabRef · Siedlerchr · Jun 12, 2022 · Jun 12, 2022
diff --git a/docs/adr.md b/docs/adr.md
diff --git a/docs/adr/template.md b/docs/adr/template.md
diff --git a/...arkdown-architectural-decision-records.md → ...0000-use-markdown-any-decision-records.md b/...arkdown-architectural-decision-records.md → ...0000-use-markdown-any-decision-records.md
@@ -1,33 +1,29 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 0
 ---
-# Use Markdown Architectural Decision Records
+# Use Markdown Any Decision Records
 
 ## Context and Problem Statement
 
-We want to record architectural decisions made in this project. Which format and structure should these records follow?
+We want to record any decisions made in this project independent whether decisions concern the architecture ("architectural decision record"), the code, or other fields.
+Which format and structure should these records follow?
 
 ## Considered Options
 
-* [MADR](https://adr.github.io/madr/) 2.1.2 – The Markdown Architectural Decision Records
 * [Michael Nygard's template](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) – The first incarnation of the term "ADR"
 * [Sustainable Architectural Decisions](https://www.infoq.com/articles/sustainable-architectural-design-decisions) – The Y-Statements
-* Other templates listed at [https://github.com/joelparkerhenderson/architecture\_decision\_record](https://github.com/joelparkerhenderson/architecture_decision_record)
+* Other templates listed at <https://github.com/joelparkerhenderson/architecture_decision_record>
 * Formless – No conventions for file format and structure
 
 ## Decision Outcome
 
-Chosen option: "MADR 2.1.2", because
+Chosen option: "MADR", because
 
 * Implicit assumptions should be made explicit.
-
   Design documentation is important to enable people understanding the decisions later on.
-
   See also [A rational design process: How and why to fake it](https://doi.org/10.1109/TSE.1986.6312940).
-
+* MADR allows for structured capturing of any decision.
 * The MADR format is lean and fits our development style.
 * The MADR structure is comprehensible and facilitates usage & maintenance.
 * The MADR project is vivid.
-* Version 2.1.2 is the latest one available when starting to document ADRs.
-
diff --git a/.../adr/0001-use-crowdin-for-translations.md → ...ions/0001-use-crowdin-for-translations.md b/.../adr/0001-use-crowdin-for-translations.md → ...ions/0001-use-crowdin-for-translations.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 1
 ---
 # Use Crowdin for translations

diff --git a/docs/adr/0002-use-slf4j-for-logging.md → docs/decisions/0002-use-slf4j-for-logging.md b/docs/adr/0002-use-slf4j-for-logging.md → docs/decisions/0002-use-slf4j-for-logging.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 2
 ---
 # Use slf4j together with log4j2 for logging

diff --git a/docs/adr/0003-use-gradle-as-build-tool.md → ...ecisions/0003-use-gradle-as-build-tool.md b/docs/adr/0003-use-gradle-as-build-tool.md → ...ecisions/0003-use-gradle-as-build-tool.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 3
 ---
 # Use Gradle as build tool

diff --git a/docs/adr/0004-use-mariadb-connector.md → docs/decisions/0004-use-mariadb-connector.md b/docs/adr/0004-use-mariadb-connector.md → docs/decisions/0004-use-mariadb-connector.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 4
 ---
 # Use MariaDB Connector

diff --git a/...ully-support-utf8-only-for-latex-files.md → ...ully-support-utf8-only-for-latex-files.md b/...ully-support-utf8-only-for-latex-files.md → ...ully-support-utf8-only-for-latex-files.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 5
 ---
 # Fully Support UTF-8 Only For LaTeX Files

diff --git a/...ly-translated-strings-in-language-file.md → ...ly-translated-strings-in-language-file.md b/...ly-translated-strings-in-language-file.md → ...ly-translated-strings-in-language-file.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 6
 ---
 # Only translated strings in language file

diff --git a/docs/adr/0007-human-readable-changelog.md → ...ecisions/0007-human-readable-changelog.md b/docs/adr/0007-human-readable-changelog.md → ...ecisions/0007-human-readable-changelog.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 7
 ---
 # Provide a human-readable changelog

diff --git a/...08-use-public-final-instead-of-getters.md → ...08-use-public-final-instead-of-getters.md b/...08-use-public-final-instead-of-getters.md → ...08-use-public-final-instead-of-getters.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 8
 ---
 # Use `public final` instead of getters to offer access to immutable variables

diff --git a/.../adr/0009-use-plain-junit5-for-testing.md → ...ions/0009-use-plain-junit5-for-testing.md b/.../adr/0009-use-plain-junit5-for-testing.md → ...ions/0009-use-plain-junit5-for-testing.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 9
 ---
 # Use Plain JUnit5 for advanced test assertions

diff --git a/docs/adr/0010-use-h2-as-internal-database.md → ...sions/0010-use-h2-as-internal-database.md b/docs/adr/0010-use-h2-as-internal-database.md → ...sions/0010-use-h2-as-internal-database.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 10
 ---
 # Use H2 as Internal SQL Database

diff --git a/...1-test-external-links-in-documentation.md → ...1-test-external-links-in-documentation.md b/...1-test-external-links-in-documentation.md → ...1-test-external-links-in-documentation.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 11
 ---
 # Test external links in documentation

diff --git a/...different-bibEntry-formats-of-fetchers.md → ...different-bibEntry-formats-of-fetchers.md b/...different-bibEntry-formats-of-fetchers.md → ...different-bibEntry-formats-of-fetchers.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 12
 ---
 # Handle different bibentry formats of fetchers by adding a layer

diff --git a/...3-add-native-support-biblatex-software.md → ...3-add-native-support-biblatex-software.md b/...3-add-native-support-biblatex-software.md → ...3-add-native-support-biblatex-software.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 13
 ---
 # Add Native Support for BibLatex-Software

diff --git a/...-URL-creation-to-enable-proper-logging.md → ...-URL-creation-to-enable-proper-logging.md b/...-URL-creation-to-enable-proper-logging.md → ...-URL-creation-to-enable-proper-logging.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 14
 ---
 # Separate URL creation to enable proper logging

diff --git a/...ract-query-syntax-for-query-conversion.md → ...ract-query-syntax-for-query-conversion.md b/...ract-query-syntax-for-query-conversion.md → ...ract-query-syntax-for-query-conversion.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 15
 ---
 # Query syntax design

diff --git a/docs/adr/0016-mutable-preferences-objects.md → ...sions/0016-mutable-preferences-objects.md b/docs/adr/0016-mutable-preferences-objects.md → ...sions/0016-mutable-preferences-objects.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 16
 ---
 # Mutable preferences objects

diff --git a/docs/adr/0017-allow-model-access-logic.md → ...ecisions/0017-allow-model-access-logic.md b/docs/adr/0017-allow-model-access-logic.md → ...ecisions/0017-allow-model-access-logic.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 17
 ---
 # Allow org.jabref.model to access org.jabref.logic

diff --git a/...sion-to-split-multiple-sentence-titles.md → ...sion-to-split-multiple-sentence-titles.md b/...sion-to-split-multiple-sentence-titles.md → ...sion-to-split-multiple-sentence-titles.md
@@ -1,5 +1,5 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 18
 ---
 # Use regular expression to split multiple-sentence titles

diff --git a/...ment-special-fields-as-separate-fields.md → ...ment-special-fields-as-separate-fields.md b/...ment-special-fields-as-separate-fields.md → ...ment-special-fields-as-separate-fields.md
@@ -1,12 +1,12 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 19
 ---
 # Implement special fields as separate fields
 
 ## Context and Problem Statement
 
-How to implement special fields in bibtex databases?
+How to implement special fields in BibTeX databases?
 
 ## Considered Options
 
@@ -52,7 +52,7 @@ keywords = {prio1, printed, read}
 ```
 
 * Good, because does not bloat the BibTeX file. Typically, 50% of the lines are special fields
-* Good, because the user can easily assign a special field. E.g, typing “, prio1” into keywords instead of “\n  priority = {prio1},”
+* Good, because the user can easily assign a special field. E.g, typing “, prio1” into keywords instead of “`\n  priority = {prio1},`”
 * Bad, because they need to be synchronized to fields (because otherwise, the maintable cannot render it)
 * Bad, because keywords are related to the actual content
 * Bad, because some users want to keep publisher keywords
@@ -70,7 +70,7 @@ jabrefspecial = {prio1, printed, red}
 
 ### Special fields as sub-feature of groups
 
-* Good, because one concept rulez them all
+* Good, because one concept rules them all
 * Good, because groups already provide [explicit handling of certain cases](https://docs.jabref.org/finding-sorting-and-cleaning-entries/groups#types-of-groups): groups based on keywords and groups based on author's last names
 * Bad, because main table implementation changes: Currently, each column in the main table represents a field. The main may [mark entries belonging to certain groups](https://docs.jabref.org/finding-sorting-and-cleaning-entries/groups#group-color-bars-in-the-entry-table), but does offer an explicit rendering of groups
 * Bad, because groups are more a query on data of the entries instead of explicitly assigning entries to a group

diff --git a/...dr/0020-use-Jackson-to-parse-study-yml.md → ...ns/0020-use-Jackson-to-parse-study-yml.md b/...dr/0020-use-Jackson-to-parse-study-yml.md → ...ns/0020-use-Jackson-to-parse-study-yml.md
@@ -1,13 +1,13 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 20
 ---
 # Use Jackson to parse study.yml
 
 ## Context and Problem Statement
 
 The study definition file is formulated as a YAML document.
-To accessed the definition within JabRef this document has to be parsed.
+To access the definition within JabRef this document has to be parsed.
 What parser should be used to parse YAML files?
 
 ## Considered Options
@@ -20,7 +20,7 @@ What parser should be used to parse YAML files?
 
 ## Decision Outcome
 
-Chosen option: Jackson, because as it is a dedicated library for parsing YAML. yamlbeans also seem to be viable. They all offer similar functionality
+Chosen option: Jackson, because as it is a dedicated library for parsing YAML. `yamlbeans` also seem to be viable. They all offer similar functionality.
 
 ## Pros and Cons of the Options
 

diff --git a/docs/adr/0021-keep-study-as-a-dto.md → docs/decisions/0021-keep-study-as-a-dto.md b/docs/adr/0021-keep-study-as-a-dto.md → docs/decisions/0021-keep-study-as-a-dto.md
@@ -1,13 +1,13 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 21
 ---
 # Keep study as a DTO
 
 ## Context and Problem Statement
 
 The study holds query and library entries that could be replaced respectively with complex query and fetcher instances.
-This poses the question: should the study remain a pure DTO object or should it contain direct object instances?
+This poses the question: should the study remain a pure DTO object, or should it contain direct object instances?
 
 ## Considered Options
 
@@ -16,7 +16,7 @@ This poses the question: should the study remain a pure DTO object or should it
 
 ## Decision Outcome
 
-Chosen option: "Keep study as DTO and use transformators", because comes out best (see below).
+Chosen option: "Keep study as DTO and use transformers", because comes out best (see below).
 
 ## Pros and Cons of the Options
 
@@ -30,5 +30,5 @@ Chosen option: "Keep study as DTO and use transformators", because comes out bes
 
 * Good, because no need for database and query entries
 * Bad, because custom de-/serializers for fetchers and complex queries needed
-* Bad, because harder to maintain than using "vanilla" jackson de-/serialization
+* Bad, because harder to maintain than using "vanilla" Jackson de-/serialization
 * … <!-- numbers of pros and cons can vary -->
diff --git a/...stop-words-during-query-transformation.md → ...stop-words-during-query-transformation.md b/...stop-words-during-query-transformation.md → ...stop-words-during-query-transformation.md
@@ -1,12 +1,12 @@
 ---
-parent: Architectural Decisions
+parent: Decision Records
 nav_order: 22
 ---
 # Remove stop words during query transformation
 
 ## Context and Problem Statement
 
-When quering for a title of a paper, the title might contain stop words such as "a", "for", "and". Some data providers return 0 results when querying for a stop word. When transforming a query to the lucene syntax, the default Boolean operator `and` is used. When using IEEE, this often leads to zero search results.
+When querying for a title of a paper, the title might contain stop words such as "a", "for", "and". Some data providers return 0 results when querying for a stop word. When transforming a query to the Lucene syntax, the default Boolean operator `and` is used. When using IEEE, this often leads to zero search results.
 
 ## Decision Drivers
 
@@ -27,11 +27,11 @@ Chosen option: "Remove stop words from the query", because comes out best.
 
 ### Remove stop words from the query
 
-* Good, because Good search results if no Boolean operators are used
-* Bad, because When using complex queries and stop words are used alone, they are silently removed
+* Good, because good search results if no Boolean operators are used
+* Bad, because when using complex queries and stop words are used alone, they are silently removed
 
 ### Automatically enclose in quotes if no Boolean operator is contained
 
-* Good, because Good search results if no Boolean operators are used
-* Bad, because Silently leads to different results
-* Bad, because Inconsistent to Google behavior
+* Good, because good search results if no Boolean operators are used
+* Bad, because silently leads to different results
+* Bad, because inconsistent to Google behavior