Process Organization - From Idea to Release

Coming soon....

Tractus-X Process Overview

We use the Committees and Expert Groups of the Catena-X e.V. to align, develop and release Catena-X specifications and standards (candidates) - also with other initiatives in the future. We use the Eclipse Tractus-X Project (e.g., TRGs), the Eclipse Development Process to refine, plan, develop and release our implementation features.

Catena-X Process Overview

Tasks	Documents (e.g. Standards)	Reference Impl.	Outcome
Feature Proposal	Refinement Meetings	In sig release	Proposals by C-X e.V. Overview of all feature proposals incl. acceptance criteria. (Task break down over all affected teams / dependencies.) DOE ???
Feature Commitment	Planning Meetings	In sig release	Decision by committer group Committed, prioritized backlog for the next release. Coordination / refinement / prioritization of new ideas, business requirements, features (scope C-X only)
	C-X association tooling	Sig-release	Priotized list of Catena-X business requirements (proposal)
	C-X association tooling	Sig-release: Discussions, Issues	Product Priotized list of overall business requirements
	Association meetings (e.g., roadmap)	Tractus-X open meetings (e.g., refinement, planning, …)	Roadmap and issues updated (?)
Development of Deliverable	Create (normative) documents	Create open source software / KITs	Deliverables created (Normative Documents, KITs, Reference Implementation (complies to C-X Standards))
Review of Deliverables	Content reviews in expert group	Code reviews (PRs) in Tractus-X	Deliverables reviewed
Testing of Deliverables	Member Sounding	Testing of software, test phase, test management, etc.	Deliverables tested
Release Deliverables	Quality Criteria and Style Guides	Tractus-X Release Guidelines	Deliverables released

Propose and plan

Feature proposal

New feature proposal have to be created in the SIG-release repository.

Mandatory feature content (Subset of the DoE for the proposal)

• Feature author defined: The designated point of contact for any questions related to the feature during the refinement, planning and development phase (e.g., subject matter expert). Not necessarily responsible for the technical implementation of a feature. Additionally, the clarification of developer resource commitment must be initiated*.
• (High-Level) feature desciption is available
• Business value is defined
• Accpetance criteria are defined
• Dependencies with other products or issues are identified and categorized via GitHub labels
• Known risks are properly adressed ...

The general communication will happen via the created feature (issue).

*There are two options regarding resource commitment:

1. If you have dedicated developer resources, your developer team will create the implementation issues at the user story level.
2. If you do not have dedicated developer resources, interested developers team can create the implementation issues.

Feature assignment & validation

Responsible: Committee & Expert group

Once a new feature proposal has been made for the Tractus-X project, it enters a validation phase where the committees assigns it to the relevant expert group.

• Validation: The committee assignes the feature to the matching expert group (at least two specific contacts). The expert group will review the proposal to ensure it aligns with the project's goals and standards.
• Request for Additional Details: If the proposal lacks necessary details, the reviewing bodies may ask the author for additional information or clarification.

Feature refinement

Responsible: Feature author

After being validated and initially prioritized by the expert group, the refinement process starts. The feature author must gather their peer group (such as experts, contributors, and committers) for example by publishing a virtual meeting invite for the feature issue to be refined.

The goal is to have features that fullfill the following Definition of Entry (DoE):

• Feature author defined: The designated point of contact for any questions related to the feature during the refinement, planning and development phase (e.g., subject matter expert). Not necessarily responsible for the technical implementation of a feature.
• Feature desciption is available
• Required enablers are defined and aligned (e.g., architecutre, infrastructure, compliance)
• High-level architecture (building-block-view)
• Key dates and milestones are defined using GitHub milestone declaration
• Business value is defined
• Test scenarios, test cases and test data are available
• Accpetance criteria are defined
• Feature estimation available (based on story points)
• Developer team for feature implementation defined
• Dependencies with other products or issues are identified and categorized via GitHub labels
• Known rsiks are properly adressed
• No open questions left
• First implementation issues are defined in the corresponding repository and linked to the feature (optional) ...

Ultimately, the decision regarding maturity is made jointly by the affected products and contributers in the open refinement meetings.

Feature author responsibility in the refinement:

• Responding to feedback: The author is responsible for addressing any feedback provided by the expert group or committee. This may include providing additional details or making revisions to the proposal.
• Implementation issues: If necessary, the author may need to create implementation issues in the repository of the corresponding product to break down the feature into manageable pieces. This aids in tracking progress and facilitates easier review.
• Timely Updates: The author must update the feature details within the given timeframe. Prompt responses and updates are crucial to keep the proposal moving forward.

Feature validation and approval

Responsible: Feature author

• Approval for Planning: Once the feature has sufficient details and meets the Definition of Done (DoE), the feature author needs to submit it to the committee or expert group (specific contacts mentioned in the feature) and a committer for approval.
• Status of the Feature in the SIG-release repository will be set to 'Backlog' by a committer (in alignment between expert group, committee and the respective feature author). This status indicates whether the feature is included in the list for open planning or not.
• Continuous Communication: The author should maintain close communication via the feature issue with the expert group and committee throughout this process to ensure prompt resolution of any issues.

Open Planning

Responsible: Feature author

During the open planning meeting, the feature author must present the features they are responsible for, and the committers will prioritize them in alignment with the expert group.

• Open Planning Cut-off: Features must have mandatory content from the DoE and approval (2.3) before the open planning meeting. This is a critical deadline.
• Consequences of Missing Deadline: If the feature does not meet the DoE or missing the approval by the open planning, it will not be included in the planning cycle. This means it will likely be deferred to a future release.

By following this process, authors can ensure their feature proposals are considered for inclusion in the Tractus-X project's planning. It is important to be proactive, responsive, and detail-oriented to successfully navigate the post-proposal phase.

Open Release Planning Meeting

Once a feature is through the propose and refinement process (2.) the feature will be presented in the open planning meeting and the committer will prioritize them based on the strategic / technical fit and ressource commitment in alignment with the expert groups of the Catena-X association.

The open release planning meeting also called Program Increment (PI) planning is a critical event in the Tractus-X project where contributors, committers, expert groups, and committees come together to define the scope for the next release. This process ensures that the project's roadmap is aligned with stakeholder expectations and the project's strategic objectives. Here's how the release Planning process typically unfolds:

• Attendees: Contributors, committers, expert groups, and committees attend the release planning meeting.
• Scope Definition: The main objective of this meeting is to determine the scope of the upcoming release. This involves discussing the refined features and confirming the prioritized backlog.
• Priorize backlog: The backlog will be reviewed to ensure that it aligns with the project's strategic direction and available resources. Before the open release planning meeting, committees and expert groups can pre-prioritize the backlog. However, the final prioritization is done by the committers.

Decision-Making by Committers

• Realistic Scope Assessment: Committers play a crucial role in the release planning process. They assess the proposed features and backlog issues to determine what is realistically achievable in the next release, considering review, maintenance, and test efforts.
• Final Prioritization: Committers have the final call on the prioritization of issues, ensuring that the most critical and feasible items are included in the release scope.
• Resource Allocation: Decisions regarding the allocation of resources, including developer time and testing infrastructure, are made to support the prioritized issues.

Outcome of Open Planning

• Priortized backlog: Decision by committer group Committed, prioritized backlog for the next release.
• Resource commitment: Teams and individuals commit to the work they will deliver, fostering accountability and setting clear expectations for the upcoming release.
• Updated roadmap: The project's roadmap is updated to reflect the decisions made during the release planning, providing transparency to stakeholders and the community. [TO-DO clarifiy location of the roadmap / where will this be published]
• Decisions are documented: All decisions and commitments made during the planning are documented in the decision board or directly in the comment section of a feature. [TO-DO link to the architecture decsion board]
• Communication plan: After the planning a communication via mailing-list will be done by the project lead including the relevant links and decisions.

Feature Development

1. Sprint Planning by committer
2. Sprint Review by committer
3. Recommended: Product demo as soon as relevant feature(s) are ready to show to get feedback from the community (prototypes are also welcome)

For open-source reference implementations please refer to the Eclipse Handbook and the Tractus-X release guidelines..

Test Management

The software testing of reference implementations is sponsored and coordinated by the Catena-X association. It includes the following three levels:

• Level 1: Product Tests
• Level 2: Release Tests
• Level 3: Test Beds for 3rd Party Solutions

Product Tests

Product tests include unit, regression and integration tests based on product helm charts with individual dependencies.

Contributors can create pull requests (PRs) for their developed features at any time. A PR must be assigned to a feature issue committed in the open planning. To get faster code reviews, it is recommended to submit small PRs.

A PR must include the feature code, adapted helm chart(s), technical documentation as well as product tests (e.g., unit tests) and product integration tests (e.g., by using helm charts or mocks). All these tests must be passed locally before the PR can be submitted.

Hint: You can find the latest versions of the product helm charts in our release changelog.

At least two committer must review the PR, including the source code, test results and the compliance with the Tractus-X release guidelines (TRGs), and approve the merging of these changes. In case there are change requests or defects that a committer cannot solve, the contributor must address these changes before merging.

The PR and the related product tests are part of the open-source development process resulting in a new product (rc-)version.

Release Tests

The release tests include e2e tests for the Catena-X operating system (cxOS) itself as well as for the cxOS with open-source applications (e.g., Trace-X) based on umbrella helm charts. Thereby, various product combinations of umbrella helm charts are possible.

The purpose of release testing is for the feature requestor to validate the end-to-end business flow using various test executions and to confirm that the acceptance criteria have been fulfilled (business value).

Before a product can participate in a release test, it must fulfill the following prerequisites:

For release 24.08, expert groups of the Catena-X association must ...

• create new or refine existing e2e test cases, test data and documentation as .md-file in Tractus-X sig-testing.
• provide at least one tester for the execution of the e2e test cases (if not fully automated).

The Catena-X association will provide a test management team including ...

• a test manager that creates the test plan and report, coordinates the test execution.
• a DevSecOps engineer for setting up test environment infrastructure (based on the hotel budapest approach).
• a DevSecOps engineer for deploying the umbrella helm chart of release candidates (supported by Tractus-X committer, if not fully automated yet).

The release tests result in a validated version of the cxOS, which is made available through quarterly Eclipse Tractus-X releases.

Test Beds

Coming soon...

Defect Management

Defects or unexpected behavior must be reported as bugs in the sig-release repo.

Test Artifacts

There are various testing artifacts, that are either managed in Tractus-X GitHub or the Test Management Tool.

• In GitHub we manage the different user journys and related business scenarios as .md files.
• In the Test Management Tool we manage test cases, test sets (opt.), test exectuions as well as test plans and reports.

Artifact	Artifact Owner	# per Release
Test Case(s)	Product / Expert Group	n
Test Set(s)	Product / Expert Group	n
Test Execution(s)	Product / Expert Group	n
Test Plan	Test Manager	1
Test Report	Test Manager	1

Release Management

info

ToDo: Release

Security Mangement

info

ToDo: Security, Managing and Reporting Vulnerabilities, Communication

Relevant Links

• Catena-X Community Introduction

FAQs

How are the open meetings communicated? The Catena-X association will communicate and coordiante the open refinement and open planning meetings vi the a Tractus-X News Page and the Tractus-X Mailing List. Please make sure that you subscribe. The meetings will also be published (with meeting session and calender.ics) on the open meetings page.

Who can propose a feature? Anyone can propose a feature, including committees, expert groups, and other initiatives. However, we require a dedicated feature author for further refinement and the breakdown into implementation issues.

How to handle dependencies? Dependencies can be discussed in our open refinement meetings as well as via our other communication channels (e.g. martix chat or bilateral sessions). Please refer to our Tractus-X communication rules.

Who gives access to the sig-release repository to enable planning process? Please refer to our Tractus-X Getting Started Guide.