Skip to content

Home

Jump to bottom
ds-mkanal edited this page Feb 20, 2024 · 54 revisions

This page will guide you through the main lean principles applying to this project, its processes, how you can participate.

Vision and Mission Statement

Description

In general, the following applies to the IRS:

The Catena-X data sovereignty principles apply to the Item Relationship Service Data Access, policies, and contract negotiation will be done by the EDC The IRS simplifies the interaction with data chains, which are based on the digital twin concept and the designed relationships between these digital twins.

Capabilities

The IRS enables to apply business logic along a distributed data chain, for example aggregation of certificates along the value chain.

Ad-hoc development of continuous data chains across company boundaries for empowerment of the use cases Circular Economy, Traceability, Quality and the European supply chain act.

Working Agreement

  • We work as one team towards a common goal, vision and clear scope.

  • We make sure everyone’s voice is heard and listened to.

  • Technical Excellence - Keep on improving, stabilizing, improving quality of this project at any time

  • Clean Code

  • Technical Excellence with a lean approach

  • Keep break the complexity down

Communication Channels

For Tractus-X project relevant topics use: If you need to get in contact with the Catena-X e.v. association use: https://catena-x.net/en/offers-standards/item-relationship-service or info@catena-x.net

All project specific communication will be handled within this repository. Use:

  • issues for bugs, or security voulnerabilities

  • comments to participate on features or stories topics

  • discussions to participate an conceptual work

  • chat to get direct contact with the team https://chat.eclipse.org

more information on how to be part of the community: https://eclipse-tractusx.github.io/community/

Usage of Communication about CVEs

Matrix IRS Chat

[Matrix Chat ](https://matrix.to/#/#tractusx-irs:matrix.eclipse.org) * Technical discussions * Feature discussions * Communication about CVEs

Teams IRS Chat

  • Deployment on CATENA-X infrastructure

  • Absence Notifications

  • Sick Leave / Vacation

  • Stuff and topics which is not allowed to share in the public (Compliance C-X)

IRS Project States

%%{init: {'theme':'dark'}}%%
flowchart LR
    0([new issue\n bug\nsecurity finding])
    inbox([INBOX])
    backlog([BACKLOG])
    next(NEXT)
    wip(WORK IN PROGRESS)
    inr(IN REVIEW)
    done(DONE)
    0 --> inbox
    inbox -.->|refinement\nmeeting| backlog
    backlog -.->|iteration planning\nmeeting| next
    next -.-> wip
    wip -.-> inr
    inr -.-> done
    
    style inbox fill:#2d333b,stroke:#444c56,stroke-width:0.5px,color:#768390
    style backlog fill:#4184e41a,stroke:#4184e466,stroke-width:0.5px,color:#539bf5
    style next fill:#46954a26,stroke:#46954a66,stroke-width:0.5px,color:#57ab5a
    style wip fill:#ae7c1426,stroke:#ae7c1466,stroke-width:0.5px,color:#c69026
    style inr fill:#cc6b2c1a,stroke:#cc6b2c66,stroke-width:0.5px,color:#cc6b2c
    style done fill:#986ee21a,stroke:#986ee266,stroke-width:0.5px,color:#986ee2
Loading
githubprocess

INBOX

All new issues (Bugs, Stories, Security vulerabilities) will be collected in the inbox.

BACKLOG

Issues which have already been sighted and some first refinement has been conducted. Issues within the backlog are reasonable items, which will be further dealt within the development of this project. The issue needs to match to the vision and mission of this project!

NEXT

This State reflects a Sprint based log of issues, which are planned to be finished within the sprint.

WIP

Currently Issues, which work is in progress.

IN REVIEW

Issues on which the review process and test are being conducted.

Review Process

  • Ask a team member to perform the review, in the daily and assign the ticket accordingly. Assign the PR to the team member.

  • PR’s should take precedence over starting new tasks. Getting some things done is better than starting many things.

  • The reviewer checks the implemented ticket for correctness, completeness and quality and leaves comments in the PR or the ticket if necessary.

  • If changes are necessary, comment it in the pull request.

  • To achieve a uniform standard, follow Google’s Code Review Developer Guide

Test Process

  • Currently done outside this project!

DONE

Issues which are completed

WONT DO

This status will not be part of the boards. If tickets need to be close, which will not be implemented, the Github functionality to close an issue is being used! github-close.jpg

Code Management

  • Commits according to the following convention: 

    <type>(optional scope):[<Ticket_ID>] <description>
    see ConventionalCommits.org for more information

Pull Request

The goal is that the maximal life cycle of a pull request: 1.5 days.

Steps:

  • Every developer creating a pull request is responsible to assign a reviewer.

  • Please check the availability of a reviewer.

  • If Review needs to be planned: Use PR’s or Issues comment functionality to get in contact with a project committer

Branching

branching

  • main dev work is done on feature branches

  • Branches must be prefixed according to their nature:

    • feature/* - for implementing user stories

    • fix/* - for fixing bugs that appeared in the main branch

    • chore/* - any small change without any impact on the software Branch Name:

  • MUST contain: Subject of issue (Abbreviation of Issue without using spaces / use "-" to connect)

Documentation

logo_tractus-x.svg

Clone this wiki locally