• We work as one team towards a common goal, vision and clear scope.
• We make sure everyone's voice is heard and listened to.
• Furthermore, we show all team members equal respect.
• We make sure to spread our expertise and skills in the team, so no single person is relied on for one skill.
• Meetings longer than 30 minutes should start 5 minutes later

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

• issues for bugs, or security vulnerabilities
• comments to participate on features or stories topics
• discussions to participate an conceptual work
• chat to get direct contact with the team https://matrix.to/#/#tractusx-trace-x:matrix.eclipse.org

%%{init: {'theme':'dark'}}%%
flowchart LR
    0([new issue\n bug\nsecurity finding])
    inbox([INBOX])
    backlog([BACKLOG])
    next(NEXT)
    wip(WORK IN PROGRESS)
    test(TEST)
    inr(IN REVIEW)
    done(DONE)
    0 --> inbox
    inbox -.->|refinement\nmeeting| backlog
    backlog -.->|iteration planning\nmeeting| next
    next -.-> wip
    wip -.-> test
    test-.-> 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

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

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!

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

Currently Issues, which work is in progress.

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

• 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 https://google.github.io/eng-practices/review/ [Google's Code Review Developer Guide]

• Currently done outside of this project!

Issues which are completed

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!

• Commits according to the following convention:

<type>(optional scope):[<Ticket_ID>] <description>

see https://www.conventionalcommits.org/en/v1.0.0/[ConventionalCommits.org] for more information

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

• 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)

• GitHub Documentation
• Product documentation is managed here: https://github.com/eclipse-tractusx/traceability-foss/tree/main/docs/src/docs

• Issue The User Story has a short and comprehensive summary/title
• Person, who is responsible for getting the user story within one iteration done.
• User Story As a , I want so that .
• Linked Issues is used to show up dependencies and links to parent features
• The User Story is estimated (Story Points) (e.g. using the Fibonacci sequence). (The effort involved in documentation, creation of test cases, implementation of the non-functional requirements, if applicable, etc. must also be taken into consideration.)
• The User Story has sufficient acceptance criteria and is accepted by the team
• Acceptance Criteria is written in the GIVEN-WHEN-THEN format, if applicable.
• The non-functional requirements applicable to the User Story are mentioned and accepted by the team