docs: Define how to handle ADR PRs #13644

evgenyz · 2025-06-29T12:25:36Z

Description:

We should keep the changes related to a proposed ADR at bay until the ADR is accepted.

Rationale:

It'd allow us to protect the project from proposal creep-in.

Review Hints:

Alternative for #13614.

qlty-cloud-legacy · 2025-06-29T12:41:18Z

Code Climate has analyzed commit e227437 and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 100.0% (50% is the threshold).

This pull request will bring the total coverage in the repository to 61.9% (0.0% change).

View more on Code Climate.

marcusburghardt · 2025-07-02T11:08:18Z

docs/manual/developer/11_governance.md

@@ -86,7 +86,9 @@ All issues and pull requests for product removal must use the [product-removal](
 #### Architectural Decision Records
 - We use [Architectural Decision Records](#introduction-of-architecture-decisions-records)
 - The first ADR defines the context and guidelines for new ADRs.
-
+- All PR that support or justify a proposed ADR should be linked to that ADR in the description and should remain in the draft state until ADR is accepted.


I imagine cases where a new contributor opens a PR without knowing it could be impacted or related to a proposed ADR. But maintainers would be aware of this during the review. So, we could also include a sentence on how maintainers should proceed in this case. Basically to inform other reviewers and also guide the author through the process.

Using dedicated label could be good to easily bring visibility on these PRs.

I've added something along the lines.

Mab879

Looks good to me. Just a few minor corrections if you want to take them.

Mab879 · 2025-07-16T13:20:03Z

docs/manual/developer/11_governance.md

@@ -86,7 +86,9 @@ All issues and pull requests for product removal must use the [product-removal](
 #### Architectural Decision Records
 - We use [Architectural Decision Records](#introduction-of-architecture-decisions-records)
 - The first ADR defines the context and guidelines for new ADRs.
-
+- All PR that support or justify a proposed ADR should be linked to that ADR in the description and should remain in the draft state until ADR is accepted.


Suggested change

- All PR that support or justify a proposed ADR should be linked to that ADR in the description and should remain in the draft state until ADR is accepted.

- All PRs that support or justify a proposed ADR should be linked to that ADR in the description and should remain in the draft state until ADR is accepted.

Fixed, thanks.

Mab879 · 2025-07-16T13:21:29Z

docs/manual/developer/11_governance.md

@@ -86,7 +86,9 @@ All issues and pull requests for product removal must use the [product-removal](
 #### Architectural Decision Records
 - We use [Architectural Decision Records](#introduction-of-architecture-decisions-records)
 - The first ADR defines the context and guidelines for new ADRs.
-
+- All PR that support or justify a proposed ADR should be linked to that ADR in the description and should remain in the draft state until ADR is accepted.
+  In case a PR linked to an ADR would be found valuable to the project in isolation from the ADR, reviewers may decide to unlink the PR from ADR, switch it


Suggested change

In case a PR linked to an ADR would be found valuable to the project in isolation from the ADR, reviewers may decide to unlink the PR from ADR, switch it

In case a PR linked to an ADR is found to be valuable to the project in isolation from the ADR, reviewers may decide to unlink the PR from ADR, switch it

Fixed, thanks.

Mab879 · 2025-07-16T13:23:32Z

docs/manual/developer/11_governance.md

-
+- All PR that support or justify a proposed ADR should be linked to that ADR in the description and should remain in the draft state until ADR is accepted.
+  In case a PR linked to an ADR would be found valuable to the project in isolation from the ADR, reviewers may decide to unlink the PR from ADR, switch it
+  to the ready state and proceed with the PR in a regular way.


Suggested change

to the ready state and proceed with the PR in a regular way.

to the ready state and proceed with the PR via the normal process.

Fixed, thanks.

evgenyz · 2025-07-25T10:14:13Z

I'll add the ADR label after the change is merged.

Mab879 · 2025-07-25T20:23:50Z

I'm not seeing any new commits. Did you forget to push?

Mab879

LGTM.

dodys

lgtm, thanks!

marcusburghardt

The content LGTM. There is just a minor typo.

docs/manual/developer/11_governance.md

We should keep the changes related to a proposed ADR at bay until the ADR is accepted. It'd allow us to protect the project from proposal creep-in.

marcusburghardt

LGTM. Thanks

Mab879 · 2025-07-28T16:59:32Z

We have three approvals. Merging, thanks!

marcusburghardt reviewed Jul 2, 2025

View reviewed changes

evgenyz mentioned this pull request Jul 16, 2025

docs: Add and ADR about handling ADR-related PRs #13614

Closed

evgenyz requested review from a team July 16, 2025 10:41

Mab879 reviewed Jul 16, 2025

View reviewed changes

Mab879 added this to the 0.1.78 milestone Jul 16, 2025

evgenyz requested review from Mab879 and marcusburghardt July 25, 2025 10:14

evgenyz force-pushed the doc-add-adr-embargo-prs branch from e227437 to 5772d3b Compare July 25, 2025 20:40

Mab879 approved these changes Jul 25, 2025

View reviewed changes

dodys approved these changes Jul 28, 2025

View reviewed changes

marcusburghardt requested changes Jul 28, 2025

View reviewed changes

docs/manual/developer/11_governance.md Outdated Show resolved Hide resolved

docs: Define how to handle ADR PRs

08b3b7c

We should keep the changes related to a proposed ADR at bay until the ADR is accepted. It'd allow us to protect the project from proposal creep-in.

evgenyz force-pushed the doc-add-adr-embargo-prs branch from 5772d3b to 08b3b7c Compare July 28, 2025 14:38

marcusburghardt approved these changes Jul 28, 2025

View reviewed changes

Mab879 merged commit 7f73eff into ComplianceAsCode:master Jul 28, 2025
128 of 129 checks passed

	- All PR that support or justify a proposed ADR should be linked to that ADR in the description and should remain in the draft state until ADR is accepted.
	- All PRs that support or justify a proposed ADR should be linked to that ADR in the description and should remain in the draft state until ADR is accepted.

	In case a PR linked to an ADR would be found valuable to the project in isolation from the ADR, reviewers may decide to unlink the PR from ADR, switch it
	In case a PR linked to an ADR is found to be valuable to the project in isolation from the ADR, reviewers may decide to unlink the PR from ADR, switch it

	to the ready state and proceed with the PR in a regular way.
	to the ready state and proceed with the PR via the normal process.

docs: Define how to handle ADR PRs #13644

docs: Define how to handle ADR PRs #13644

Uh oh!

Conversation

evgenyz commented Jun 29, 2025

Description:

Rationale:

Review Hints:

Uh oh!

qlty-cloud-legacy bot commented Jun 29, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mab879 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

evgenyz commented Jul 25, 2025

Uh oh!

Mab879 commented Jul 25, 2025

Uh oh!

Mab879 left a comment

Choose a reason for hiding this comment

Uh oh!

dodys left a comment

Choose a reason for hiding this comment

Uh oh!

marcusburghardt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

marcusburghardt left a comment

Choose a reason for hiding this comment

Uh oh!

Mab879 commented Jul 28, 2025

Uh oh!

Uh oh!

Uh oh!