How to start your Contribution Journey

Active Contributions to the S-CORE project are the basis for getting involved. The S-CORE Project works according to the Eclipse Project Handbook and has named and elected project leads and committers (see Eclipse Safe Open Vehicle Core ).

The direction of the S-CORE project is discussed and decided in the project lead circle, the technical direction is created and upfront in the tech lead circle. Meeting notes are transparent via the S-CORE GitHub Discussions.

We aim to build a safety ready full stack architecture, where components fit to each other in automotive grade Software Quality and performance. To achieve this, we follow a strict feature roadmap and architecture and a rigid software development process

Contributions to the S-CORE project must therefore follow the technical direction of the project and the S-CORE architecture. For an introduction on how to contribute, please check out our Contribution Guideline.

Based on successful code contributions to the S-CORE roadmap, further steps in involvement (like becoming a committer) will be handled according to the rules of the Eclipse Foundation Project Handbook. We value real code based collaboration and will judge new potential contributors and committers mainly on the validity of their work. Active and sustaining contributions are the basis for the ability to shape S-CORE.

Feature Requests: Our Shared Roadmap

Feature requests are at the heart of our evolution. They describe the intended functionality of the S-CORE platform and serve as a collaborative starting point where maintainers and contributors align on new ideas. These requests not only define the motivation and requirements but also shape the technical roadmap for future developments. We invite you to check out all current feature requests on our Feature Request Board.

From Vision to Reality: Calling for Contributions

Once a feature request is embraced by the community, it becomes a targeted opportunity for innovation. At this stage, we issue a call for contributions, inviting anyone with a solution - whether in-house or open source - to submit a contribution pitch. We ask that your pitch focuses on the technical aspects and clearly outlines how you plan to meet the feature goals (and not a sales pitch 😉). Don’t worry if you’re still polishing your idea; as long as the source code is already available (or will be within about three weeks with a publicly committed roadmap), you’re ready to join in the conversation.

How We Evaluate Contribution

We work together with contributors to review each pitch based on several criteria: Alignment with the Feature Request: Your solution should fully or partially meet the specified functionality, with room for further enhancements as needed. Availability of the Source Code: We value open source solutions under an OSI-compliant license. If your code isn’t public yet, a clear plan to open source it is just as welcome. Technical Maturity: We look at whether your implementation is built in a safety-certifiable subset of C++ or Rust, or if it might need some refinements. Initial Impact Assessment: Please state the assumed impact on other systems. It makes a significant difference if your solution requires other components to refactor versus extending functionality through existing APIs. Supporting Artifacts: To ensure everything is in order for certification and further development, we check that all necessary artifacts are available or that there’s a plan to make them available. For a deeper dive into our evaluation process, you can review the notes from our very first call for contributions on our Architecture Community F2F Workshop [2025-02-11 - 2025-02-13]. Once a contribution is selected, it not only implements a new feature but also helps guide the ongoing evolution of S-CORE. Replacement of existing functionality In S-CORE we aim for having only one solution for a specific problem. If you have an idea for improving an existing feature, you’re welcome to pitch a replacement implementation. Just be sure to highlight clearly the benefits over the current solution.

Join Us in Building S-CORE

Have a New Idea? Start by raising a new feature request to help expand the scope of our platform. Ready to Code? Submit a contribution pitch for a specific feature request if you have a solution you’d like to share. Looking to Improve What’s Already There? Contribute enhancements to existing implementations or get involved with one of our Feature Teams (FTs). We’re excited to have you on board. Together, we can shape S-CORE into a platform that’s not only innovative but also a joy to be a part of.

What is a Pull Request (PR)?

A Pull Request (PR) is the ONLY way to contribute CODE to the S-CORE project. The figure below shows a simplified workflow for a PR. The contributor (PROCESS_rl__contributor) starts by creating a PR: Creating a Pull Request (Github Docs). Required reviewers will be automatically assigned based on the contributed content (via CODEOWNERS). If the content fullfils the review and acceptance criteria, a committer (PROCESS_rl__committer) will approve the PR and thus it can be merged.

Content in general may contain features, requirements, architectural designs, modules, components, detailed designs, implementations and source code, tests, process descriptions, any documentations, guidelines, tutorials, tools, or infrastructure topics and more of the S-CORE project. In case of doubt or for any other input we strongly encourage to open a GitHub Issue (Issue Guideline (doc__issue_guideline)) first. The PR should provide all required information of the new or changed content. Therefore the S-CORE project provides content specific templates, which the contributor (PROCESS_rl__contributor) must use for his PR (ToDo link here to the templates overview). Templates may be PR templates, GitHub Issue templates and also additional document or work product templates. The content of any PR is the commit content and the description as well as the comments given in GitHub and is kept in a versioned repository, their revision history is the historical record of the PR. This historical record is available by the normal git commands for retrieving older revisions, and can also be browsed on GitHub.

Detailed S-CORE Pull Request Workflow

This chapter is only for optional read to understand the details for the Pull Request workflow defined in S-CORE.
The figure below gives an overview about all the possible steps for a PR until it is either accepted or rejected.

Create a PR

The contributor (PROCESS_rl__contributor) creates a PR. Reviewers will be automatically assigned (PROCESS_rl__committer) based on the contributed content (ruleset as defined by the committers). In addition several checks for the contributed content (ToDo: Link to the description of the checks) will be started.

Review and merge a PR

A PR is reviewed with all content that adds/modifies it. As long as a PR requires further work by the contributor (PROCESS_rl__contributor), the PR is not approved and thus not merged and further changes are requested. Once the contributor (PROCESS_rl__contributor) considers all review comments as resolved, PROCESS_rl__contributor can re-request a review. The committer (PROCESS_rl__committer) reviews the PR content according the S-CORE review and acceptance criteria (ToDo link here to the criteria). Further the contributor (PROCESS_rl__contributor) must resolve found issues from the automated checks, if they do not pass. As long as the PR does not meet the defined criteria and the checks does not pass, it will not be approved. If it does not follow the required templates, based on the provided content or the templates are not filled out properly, the committer as reviewer (PROCESS_rl__committer) will place the PR to the “Draft” state. It is then the responsibility of the contributor (PROCESS_rl__contributor) to add the missing information and to re-start the contribution by placing the PR back for review. To change from “Draft” to “Open” see Changing the stage of a pull request (Github Docs). At any point the contributor (PROCESS_rl__contributor) may decide not to continue with the PR, then the contributor (PROCESS_rl__contributor) just closes the PR.

What is a GitHub Issue?

A GitHub Issue is the way to report bugs or propose improvements without knowing the solution and to request features (incl. scope changes). For creating GitHub Issue compare here: Creating a GitHub Issue (Github Docs). Create an GitHub Issue to collect feedback, before investing too much effort into a PR. GitHub Issues may be accompanied by draft PRs if code is to be shown. It can also be used to collect community input and for planning and tracking activities. The figure below shows options to report something.