2026-05-05 - Technical Lead Workshop Ulm (Hybrid)

[FScholPer]

2026-05-05 09:00 am-15:00 pm CET hosted by Mercedes Benz Tech Innovation Location Ulm Germany

Open for remote listeners.

https://teams.microsoft.com/meet/327881327897152?p=5zDYYwG8z13XL1NIHg

Participants

@antonkri - onsite
@qor-lb / @PhilippM-qorix - onsite
@FScholPer -onsite
@anmittag - onsite
@DanielSteinkeSDV - online
@odra - online
@umaucher - onsite

~ 5h

Agenda

1. Status of V1.0 ~60min

   • scope-review and status
     score.github.io/score/main/_images/architecture_0_6.drawio.svg))

2. Orga ~10min

   • https://eclipse-score.github.io/score/main/platform_management_plan/project_management.html#project-organization
   • Teams / Stuffing / Leads
   • Discussions clean Up?
   • Maintainers

3. Planning, Tracking, Dashboards (AI-based?): ~30min

   • HowTo
     • Product Increments (TLC defines the quality steps for each Package) -> Epics -> Tasks / Bugs
   • Dashboards: Burn Downs, Roadmap, Tree view, BugsTrend (Severity, Time)
   • V0.8
     • Define Values for SCA, C0/C1, Requirements Coverage, Traceability

4. Meetings: ~15min

   • How to minimize the meetings and increase the participation
   • Alignement Meeting: Must for each Team Lead, Reference Integration Meeting: Must for one representative out of the Team

5. Finalizing the Ref Integration Selection ~30min

   • LL of Ref Int for <=V0.7 and Review the Issue list

6. Quality Status ~30min

   • SCA. UT Coverage, ... and how to reach "100%"

7. Unified Processes & Infrastructure to minimize Certification Effort ~30min

8. Stakeholder / Product Requirements ~15min

   • Ownership
   • Completeness
   • Maintaining Process

9. Interaction with other SDV activities (uProt, Blueprint, OpenSOVD, ...) ~30min

   • PreRequisites from other activities (e.g. Bazel, Q-Status)
   • How can we Integrate those parts (technically)
   • How to ensure Quality and required Artefacts
   • Comasso / AUTOSAR Onboarding Autosar #759, Architecture Community F2F Workshop [2025-04-08 - 2025-04-10] #764

10. Release Notes

    • Each Team have to create a release note with same format (Template tbd.)
    • Integration just collects building blocks and release notes and summarizes the information

Meeting Minutes

---

1. SCOPE

• ToDo
  • IVI not in scope => will be removed from Eclipse page, @b-rei already provided a PR
  • All relevant topics (for 1.0) addressed
  • Orchestration to be consolidated in ARC Team => @qor-lb
  • Prio view from ARC perspective to be provided => @qor-lb

---

2. ORG

The participants onsite, Daniel, Leonardo, and others, extensively discussed the current and future organizational structure, the definition of roles (e.g., Technical Lead Circle, Feature Team Leads, Quality Manager), and the necessity of clear responsibilities and deputies in all teams.

• Roles and Deputies: It was decided that for each community and feature team, a Lead and a Proxy (deputy) should be defined to ensure continuity during absences. The selection of proxies and the definition of responsibilities are to be made in upcoming meetings.
• Election Processes and Compliance: The group noted that the current Technical Lead Circle is not compliant with Eclipse roles, and therefore all technical leads should become project leads once the formal processes are completed.
• Community Responsibilities: For each community (e.g., Process, Architecture, Infrastructure), current Leads and Proxies were named or marked as a To-Do. It was emphasized that responsibilities must be clearly documented and regularly reviewed.
• Task Distribution: Task areas such as Organization, Planning, Quality Status, Safety, Security, Release, Integration, Process, Infrastructure, and Feature Teams were identified and are to be distributed among team members to create better overview and accountability.

• ToDos:
  • TLC to PLC conversion: members to adapted @anmittag
  • Lead and Proxies to be clarified @anmittag
  • Purpose/Responsibilities Definition for INF, TST, REL Team @PhilippM-qorix
  • Invite Quality Manager, Safety Manager, Security Manager to one of the next TLC meetings @anmittag
  • Role Description and Tasks: Create an overview with clear role definitions and tasks for all roles (e.g., Quality Manager, Safety Manager, Security Manager) and align these with the current responsible parties.

---

3. Planning & Tracking

The participants discussed release planning, the definition of goals for upcoming versions (especially 0.8 and 1.0), task prioritization, and the challenges of resource planning in an open-source environment.

• Release Cycles and Candidates: It was agreed that releases should occur every eight weeks, with a Release Candidate two weeks before the actual release. During this time, modules will be merged, and final integration work will be performed.
• Planning Meetings and Transparency: After each release, an alignment meeting should take place to define goals for the next release and prioritize the most important tasks. Teams are encouraged to make their plans and epics transparent and enter them into central dashboards.
• Challenges of Resource Planning: It was noted that resource planning is difficult because contributions from individual companies are not always transparent or predictable. Therefore, the focus should be on defining content and goals, not on fixed schedules.
• Quality Goals and Metrics: For Release 0.8, concrete quality goals such as Unit Test Coverage, static code analysis, and Requirements Coverage were defined. The achievement of these goals is to be tracked via dashboards and automated checks.

• ToDo
  • Preparing a Product Increment for each Building Block for next Release @anmittag
  • Backlog Prioritization: Create a table for prioritizing the most important open tickets per area and regularly align this with the respective leads to provide an outlook for Release 0.9.

---

4. Meetings

• ToDo
  • Synchronizing with Meeting Organizers to define needed Participants @anmittag

---

5. Reference Integration

The participants compared different approaches for reference integration (Options 1, 2, and 3), discussed their advantages and disadvantages, and agreed on closer integration and consistency checking of modules in the release process.

• Comparison of Integration Options: Option 1 (complete module autonomy) was largely ruled out as it offers too little control over toolchains and dependencies. Option 2 (centralized integration and tests) and Option 3 (hybrid approach with central dependency checking) were considered more practical.
• Consistency of Dependencies: It was decided that all modules included in a release must use the same versions of dependencies (e.g., Baselibs). This is to be ensured through central mechanisms and checks.
• Responsibilities in the Integration Process: The Release and Integration Team is responsible for carrying out central integration steps and verifying compliance with defined standards. Feature Teams must provide their artifacts and quality evidence in a timely manner.
• Technical Implementation and Decision-Making: The final decision between Option 2 and 3 is to be made by the companies. Qorix mentioned that they want the directly affected teams (e.g.,Piotr, Pawel) should decide their part, as they are responsible for the technical implementation. The discussion will continue in upcoming meetings.

• ToDo
  • Consolidate Company internal views and give your votes on the next TLC @ALL
  • Decision on Reference Integration Option: Prepare a decision template for Options 2 and 3 for reference integration and synchronize the final agreement with all relevant parties by the next alignment meeting at the latest.

---

6. Quality Status

The group intensively discussed the test concept, responsibilities for testing and quality assurance, the definition and measurement of KPIs, and the role of Quality, Safety, and Security Managers in the development process.

• Test Responsibilities: It was decided that Feature Teams are responsible for creating and executing tests, while the Testing Team provides the test infrastructure and templates. Integration tests and the review of test coverage are the responsibility of the Release or Integration Team.
• Quality Managers and KPIs: Quality Managers are responsible for defining quality goals and tracking their achievement. A Quality Management Plan exists with KPIs such as 100% Requirements Coverage and defined test coverage, which still need to be further operationalized.
• Automation and Dashboards: Dashboards and automated checks (e.g., for Unit Test Coverage, static code analysis) are to be used to monitor quality goals. The implementation and maintenance of these tools are seen as a collaborative task.
• Phased Introduction and Migration: Since not all modules can immediately meet all quality goals, a phased approach with migration paths was agreed upon. Initially, a pilot module (e.g., Baselibs) will serve as an example before the requirements are rolled out to all modules.

---

7. Unified Processes & Infrastructure
   • see 5) We are expecting that each and every Building Block is created with the S-CORE Process and Tools

---

8. Stakeholder / Product Requirements
   • Ownership: ARC
   • Completeness: To be reviewed
   • Maintaining Process: To be reviewed regularly

The group addressed the definition, maintenance, and tracking of stakeholder and process requirements, the role of the Architecture Community, and the need for clear responsibilities for requirements.

• Stakeholder Requirements: The Architecture Community was designated as accountable for creating and maintaining stakeholder requirements. It was discussed how these requirements can be effectively managed and linked to feature requirements.
• Process Requirements and Audits: The Process Community is responsible for defining and monitoring process requirements. Audits are conducted regularly, and feedback is integrated into the further development of processes.

---

9. Interaction with other SDV activities
   • see 5) We need a Team who cares about "forking" and adapting to S-CORE (Artefacts & Tools

Finally, the onboarding of AUTOSAR demonstrators and the integration of Comasso as external partners were discussed, including challenges due to IP restrictions and licensing models.

• AUTOSAR Demonstrator: It was reported that an AUTOSAR demonstrator intends to use parts of S-CORE. Integration requires adaptations to S-CORE necessities and clarification of access rights.
• Comasso Integration: The integration of Comasso was identified as a future topic, particularly with regard to the use of E2E profiles and the need for membership to access certain features.

---

10. Release Notes

• see 5)

---

Noch einzusortieren.......... Andreas

Follow-up Tasks

• Quality Management and KPIs: Review and concretize quality goals and KPIs (e.g., Unit Test Coverage, Requirements Coverage, static code analysis) for Release 0.8 and align these with the Quality Manager.

• Test Concept and Responsibilities: Develop a test concept that defines which tests are performed at which level (Feature Team, Testing Community, Test Manager) and who is responsible for their implementation.

• Dashboards and Metrics: Check which dashboards (e.g., Dora metrics, quality status) are needed and align their implementation with the Quality Manager and infrastructure responsible parties.