[Contribution Requests] Identify maintainer for the 1.0 (1st round - 4th - 6th Nov 2025) #1571
Description
Acceptance criteria:
- Contribution pitches for v1.0 modules are prepared
- Maintainer and initial contribution for v1.0 modules are agreed
Architecture Community Workshop 4th - 6th November 2025
In person pitches are preferred.
- Location: Mercedes-Benz Tech Innovation GmbH, Wilhelm-Runge-Straße 11, 89081 Ulm, Germany
- Participants: Architecture community committers & Pitch contributor +1
- Agenda: will be announced 27th October after all pitches have been announced (30 min pitch + 30 min discussion per contribution)
Process
Goal
Identify maintainers for 1.0 modules and kick-off development
What can be pitched?
- In-house solution to be contributed & maintained in S-CORE
- PoCs and techincal concepts to align implementation strategy
- Existing OSS solution to be integrated into S-CORE
How can it be pitched?
- Create a fork of the incubation repo to upstream your implementation concept (Markdown or RST)
- High-level architecture of the implementation
- Relation to the goals defined in the feature request
- 30-min technical pitch summarizing the contribution during the next architecture community workshop
In-house solution & PoCs and techincal concepts:
- Upstream your implementation in the fork
Important:
- All solutions must be open source before the contribution pitch and build successfully.
- Contribution pitches can be latest announced until 1 week before WS
How will the pitch be evaluated?
After the pitch we take a period of 2-4 weeks where the open source contributions can be evaluated offline and open questions about the implementation/concept can be clarified. The members of the architecture community and technical lead circle should target a consensus about the contribution that will be used as a basis for the 1.0 (if no consensus can be reached, we start a majority vote). The author of the contributor will also become the maintainer of this module for the 1.0 aligning further contributions in it.
Criteria
Additional:
- Extend impact analysis: Adherence to existing architecture components, e.g. if a proposal comes with its own logging or baselibs implementation, we should align how this will converge. We should avoid duplication in our architecture.
Consensus building
tl;dr: Our process handles multiple options by first seeking consensus on a single proposal. If consensus cannot be reached, competing proposals are considered, and final arbitration is made by the Technical Leads.
The goal of the architecture community is to build consensus on which contribution or approach should move forward. Consensus means that all concerns have been heard and addressed as thoroughly as possible, and that the architecture community’s committers find the outcome reasonable, even if it is not everyone’s preferred choice. Any committer of the architecture community may block a proposal if they have serious unresolved concerns, prompting further discussion or design revisions. The emphasis is on consent, decisions progress only when no maintainers raise strong objections.
The architecture community has up to 4 weeks to reach consensus after a pitch is introduced. If consensus cannot be achieved within this timeframe, the community shall present the competing proposals to the Technical Lead Circle for a resolving vote.
Voting should remain a last resort, as it inherently disregards the consent of some participants. Voting tends to create winners and losers, rather than fostering a shared understanding and solutions that meet everyone’s needs.