Create the structure to handle ADRs

- Create the structure as discussed on https://groups.google.com/d/msgid/quarkus-dev/CB395F5B-5A01-464C-8008-A0E8E7E247E6%40redhat.com?utm_medium=email&utm_source=footer
- Update the template to MADR
- Disable CI on adr update
- Configure the bot to auto-label and notify on new ADR

.github/quarkus-bot.yml

@@ -471,5 +471,10 @@ triage:
         - integration-tests/reactive-db2-client/
         - integration-tests/reactive-mysql-client/
         - integration-tests/reactive-pg-client/
+    - labels: [area/adr]
+      title: "adr"
+      notify: [cescoffier]
+      directories:
+        - adr/
   qe:
     notify: [rsvoboda, mjurc]

.github/workflows/ci-actions-incremental.yml

@@ -11,6 +11,7 @@ on:
       - '*.md'
       - '*.adoc'
       - '*.txt'
+      - 'adr/**'
       - 'docs/src/main/asciidoc/**'
       - '.github/ISSUE_TEMPLATE/**'
       - '.github/*.yml'
@@ -24,6 +25,7 @@ on:
       - '*.md'
       - '*.adoc'
       - '*.txt'
+      - 'adr/**'
       - 'docs/src/main/asciidoc/**'
       - '.github/ISSUE_TEMPLATE/**'
       - '.github/*.yml'

.github/workflows/ci-fork-mvn-cache.yml

@@ -11,6 +11,7 @@ on:
       - '*.md'
       - '*.adoc'
       - '*.txt'
+      - 'adr/**'
       - 'docs/src/main/asciidoc/**'
       - '.github/ISSUE_TEMPLATE/**'
       - '.github/*.yml'

.github/workflows/ci-sanity-check.yml

@@ -9,13 +9,15 @@ on:
       - '*.md'
       - '*.adoc'
       - '*.txt'
+      - 'adr/**'
       - '.github/ISSUE_TEMPLATE/**'
       - '.github/*.yml'
       - '.github/*.java'
   pull_request:
     paths:
       - '.gitignore'
       - '.dockerignore'
+      - 'adr/**'
       - '*.md'
       - '*.adoc'
       - '*.txt'

adr/0000-template.adoc

@@ -0,0 +1,30 @@
+= Short title
+
+* Status: [proposed | accepted | deprecated - reason: ... | superseded by [0005](0005-example.md)]
+* Date: [YYYY-MM-DD when the decision was last updated]
+
+== Context and Problem Statement
+
+Describe the context and problem statement, e.g., in free form using two to three sentences.
+You may want to articulate the problem in form of a question.
+
+== Decision Drivers (optional)
+
+* driver 1
+* driver 2
+
+== Scenarios (optional)
+
+List of scenarios, each described using 2-3 sentences, to capture where the ADR has an impact.
+
+== Considered options (optional)
+
+List of the considered options, if any.
+
+== Decision
+
+What is the change that we're proposing and/or doing?
+
+== Consequences
+
+What becomes easier or more difficult to do because of this change?

adr/README.adoc

@@ -0,0 +1,40 @@
+= ADR
+
+https://adr.github.io/[ADR] stands for _Architectural Decision Records_  and is a way to capture architectural decisions over time.
+This directory contains the ADR for the Quarkus _Core_ project.
+
+== Proposing a new ADR
+
+ADRs are contributed and edited using pull requests.
+
+- Create an asciidoc (`.adoc`) document in the _adr_ directory named "n+1-my-adr-title.adoc", with n+1 the id. Use 4 digits as id (0001, 0002...)
+- The document can be created by duplicating the _0000-template.adoc_ file. It is based on https://adr.github.io/madr/[MADR].
+- The initial state of any ADR is _proposed_.
+- Once written, open a pull request to drive the discussion. Add the `adr` label to the pull request, as well as any related area labels.
+- Before merging the ADR pull request, update the state to _accepted_.
+- Email mailto:https://groups.google.com/g/quarkus-dev[Quarkus Dev Mailing List] to inform everyone about the new ADR.
+
+The discussion around an ADR happens on the pull request.
+When the participant agrees, the ADR is marked as _accepted_, and the PR is merged.
+Be sure that all the members impacted by the ADR have the chance to read it.
+Typically, extension owners and knowledgeable people in this area should be involved in the discussion.
+If the participants disagree, the ADR is rejected, the pull request is closed.
+
+== ADR lifecycle
+
+An ADR can have the following states:
+
+- _proposed_ - Initial state
+- _accepted_
+- _deprecated_ - The ADR is not applied anymore or is out of date
+- _superseded_ - Another ADR replaces the current one. The ADR is updated with a link to the replacement.
+
+**IMPORTANT:** Once _accepted_, an ADR is immutable. Only its status and date can be updated.
+
+All modifications must be done through pull requests:
+
+* Deprecating an ADR should indicate the reason for the deprecation.
+* Superseding an ADR should be done in the same PR as the replacement ADR.
+
+
+