Skip to content

docs: Roll out DR-002-Proc FEP process across contributor docs#3076

Open
qor-lb wants to merge 1 commit into
mainfrom
qor-lb_fep_rollout
Open

docs: Roll out DR-002-Proc FEP process across contributor docs#3076
qor-lb wants to merge 1 commit into
mainfrom
qor-lb_fep_rollout

Conversation

@qor-lb

@qor-lb qor-lb commented Jul 11, 2026

Copy link
Copy Markdown
Contributor

Implements the consequences of DR-002-Proc (accepted), which introducesthe Feature & Enhancement Proposal (FEP) process for Feature and major Feature Modification change requests.

Changes:

  • feature_request.rst rewritten as the living FEP Process Guide, superseding the old TL-circle review guideline: roles, labels, the five process phases with tracking-issue lifecycle, and the FEP template.
  • change_management.rst: FEP routing added for Feature and major Feature Modification CRs.
  • software_architecture_overview.rst: references updated to the FEP Process Guide.
  • project_management.rst: Feature Request definition aligned with the FEP tracking issue (type Feature Request, may parent child Task issues for implementation tracking).

See DR-002-Proc for the decision and rationale.

Refs #3061

@github-actions

Copy link
Copy Markdown

The created documentation from the pull request is available at: docu-html

Comment thread docs/contribute/contribution_request/feature_request.rst Outdated
Comment thread docs/contribute/contribution_request/feature_request.rst Outdated

A proposal classified as **Breaking Change** must additionally include:

* **Impact Inventory**: explicit list of known integrators, configurations, or customer deliverables that will break

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right that the Breaking Change section doesnt clearly relate to FR template today, but I think the actual problem might be one level up.

The FR template currently serves two different purposes in one file: proposing a change (Motivation, Backwards Compatibility, Rejected Ideas, Open Issues - point-in-time, argument-for-the-change content) and documenting the resulting feature (Abstract, Rationale, Specification, Security/Safety Impact - living, current-state content).

My intent here (not yet fully reflected/settled): separate these explicitly. A Feature Change / FEP record carries the proposal-only content, including Backwards Compatibility, and lives with the change. Feature Documentation stays in docs/features/ with only Abstract, Rationale, Specification, Security Impact, Safety Impact, kept current as the feature evolves. Some headings would appear in both but ask a different question - e.g. Safety Impact of the feature overall vs. Safety Impact of this specific change - so one wouldnt simply reference the other.

This might be bigger than this PR since it touches FT template, used by every existing feature doc. Genuinely open on this - I would like your/the Process Communities read before committing.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment thread docs/platform_management_plan/project_management.rst
@qor-lb
qor-lb force-pushed the qor-lb_fep_rollout branch from 4ef9140 to e8953f9 Compare July 12, 2026 14:46
Implement the consequences of DR-002-Proc (FEP process) across the
four affected documents:
- feature_request.rst: rewritten as the living FEP Process Guide,
  superseding the old TL-circle review guideline. Defines roles
  (Author, Shepherd, Architecture Community), labels, the five
  process phases with tracking-issue lifecycle, and the FEP
  template.
- change_management.rst: adds FEP routing for Feature and major
  Feature Modification CRs.
- software_architecture_overview.rst: updates references from the
  old guideline to the FEP Process Guide.
- project_management.rst: aligns the Feature Request definition
  with the FEP tracking issue (type Feature Request, allowed as a
  parent to child Task issues for implementation tracking).

Assisted-by: Claude:claude-sonnet-5
@qor-lb
qor-lb force-pushed the qor-lb_fep_rollout branch from e8953f9 to 1c044ce Compare July 12, 2026 16:15
@qor-lb
qor-lb requested a review from arsibo July 12, 2026 16:17
```{dec_rec} <Short imperative title>
:id: dec_rec__<arch|proc|strat|infra|int>__<slug>
:status: draft
:tracking: <GitHub issue URL, required once a Shepherd is confirmed>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Template can be updated with this new attribute, so finally there should no specific addition, it may also be required in general, will be implemented here, eclipse-score/process_description#744

@aschemmel-tech aschemmel-tech left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a hard time to understand this, need to re-review at a later time

This Guideline is based on or references following documents:
.. _feature_request_guideline:

This guide describes how to propose a **Feature & Enhancement Proposal (FEP)** in S-CORE. FEPs are

@aschemmel-tech aschemmel-tech Jul 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

propose a proposal?

:need:`[[title]] <gd_req__change_tool_impact_analysis>`


The Decision Record Track (FEP Process)

@aschemmel-tech aschemmel-tech Jul 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does it need a new name? Below it is for example termed "FEP track"

@aschemmel-tech aschemmel-tech left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

now I re-reviewed all

community needs a structured way to reach agreement before implementation starts, rather than
relying on a single Committer's review. For these, **Analyze** is specialized into the **FEP
process**: a Shepherd sponsors the proposal, a time-boxed Final Comment Period
(silence-as-approval) replaces open-ended review, and the outcome is recorded as a Decision Record

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe better instead "replaces open-ended review" write "fosters quick decision making"

a judgment call made by the responsible :need:`Committer <rl__committer>` at the time the change is
proposed, including changes proposed directly as a PR without a prior FEP. A change can be waived
from the FEP process by community agreement if it is judged not to warrant it, or pulled into the
FEP process after the fact if a maintainer judges it major.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the "maintainer" role defined somewhere?

FEP process after the fact if a maintainer judges it major.

**Component** and **Component Modification** change requests currently go through the standard
Analyze step and are not routed onto the FEP track.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this true? I understood it differently when I was talking to @masc2023


For Change Requests routed onto the :ref:`Decision Record Track <change_mgmt_plan>`, this step is
performed as described in the :ref:`FEP Process Guide <feature_request_guideline>` instead: a
Shepherd, not a single Committer, guides the analysis, and the review window is the time-boxed

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the "review window"? Maybe "the review ends in the time-boxed Final Comment Period and not in an open-ended "in review" state?

.. _feature_request_guideline:

This guide describes how to propose a **Feature & Enhancement Proposal (FEP)** in S-CORE. FEPs are
not a separate change process: they specialize the Analyze step of the standard Change Request

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bettter describe what they are: "a part of the change process (see link) and they refine the Analyze step..."

<change_mgmt_plan>` — for *Feature* change requests and *Feature Modification* change requests with
major impact, for example changes affecting the platform or other Feature Teams.

It supersedes the previous ad hoc Feature Request review (GitHub label plus weekly Technical Lead

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather describe only what is and not what it supersedes.


Feature Request Guideline
##############################
Feature & Enhancement Proposal (FEP) Process

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that the "parent document" docs/contribute/contribution_request/index.rst talks about "Feature Requests are the heart of our evolution" - maybe add there also a reference to the "FEP Process"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Backlog
Status: No status

Development

Successfully merging this pull request may close these issues.

4 participants