docs: add DR-002-Proc — Feature & Enhancement Proposal (FEP) process

[qor-lb]

DR-002-Proc: Feature & Enhancement Proposal (FEP) Process

This PR introduces a structured FEP process for S-CORE platform-level changes and cross-Feature-Team alignment decisions.

Problem addressed:
The current feature request workflow does not differentiate proposals by architectural significance, places an unbounded review obligation on the Architecture Community, and has no defined governance path for cross-Feature-Team decisions.

What this proposes:

• A mandatory Shepherd role (Architecture Community member, not the author) that gates proposal quality before formal review
• A binding 14-day Final Comment Period where silence counts as approval
• Feature Teams retain full authority within their own domain
• FEPs are Decision Records — same format, defined governance process
• A tracking issue is created once a Shepherd is confirmed and stays open until implementation is merged

The FEP process is itself filed as DR-002-Proc, demonstrating the relationship between FEPs and Decision Records.

Prior art: Rust RFC; Kubernetes KEP; Python PEP.

Implementation: The downstream document updates listed in the Consequences section are not blocking — they will be tracked as GitHub issues linked to this DR after acceptance in: #3061

Note

This proposal was drafted with the assistance of Claude (Anthropic, claude-sonnet-4-6). The ideas, problem framing, design decisions, and all statements made in this document are my own. I have reviewed the full content, I stand behind it, and I take complete responsibility for its accuracy and appropriateness.

[github-actions]

The created documentation from the pull request is available at: docu-html
https://eclipse-score.github.io/score/pr-3007/design_decisions/DR-002-proc.html

[FScholPer]

Well done. Sounds good to me

[PandaeDo]

I'm a little bit struggling with the 10 days. Would change it to working days and maybe add something in typical vacation times to avoid that somebody tries to enforce something. What's your opinion on that?

[anmittag]

In general, the new process looks good.

But we shall use it with discipline to avoid blocking mechanism of minorities or promoting of single used solutions, etc.

[anmittag]

In general, the new process looks good.

But we shall use it with discipline to avoid blocking mechanism of minorities or promoting of single used solutions, etc.

And as already mentioned the 10 days might be not fitting.

[PandaeDo]

My findings are solved

[arsibo]

• 10 working days as time

[arsibo]

lets use the same categories as in the change mangment process

• Feature request
• Feature modification

[qor-lb]

agreed, will use the correct types during the implementation/roll out of this DR tracked in #3061