Skip to content

Home

Jump to bottom
ds-mkanal edited this page Mar 12, 2024 · 5 revisions

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

Communication Channels

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

Trace-X Project States

%%{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
Loading

INBOX

All new issues (Bugs, Stories, Security vulnerabilities) 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 https://google.github.io/eng-practices/review/ [Google's Code Review Developer Guide]

Test Process

  • Currently done outside of 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!

Code Management

  • 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

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

  • 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

Definition of Done

Item Checklist Definition of Done (DoD) Comment
1. All acceptance criteria of the user story are met 1. The User Story is fulfilling the acceptance criteria. 2. The User Story is fulfilling all the NFRs requirements
2. Quality of the US: to fulfill also related cross activities 1. Documentation covers the new/removed/modified functionality in ARC42/Admin/User manual; 2. Test Coverage is over 80% with high quality testing; 3. Security - no new CVE with severity higher than low is accepted; 4. Changelog was updated - addressing the new/removed/modified functionality; 5. IP property check is conducted for added libraries
3. Code review has been performed. 1. The code conventions for the implementation were followed; 2. Check for fulfillment of Acceptance Criteria; 3. Deployed in DEV/Test;
4. The user story has been approved by the test manager. 1. No Highest/High defects were found and left Open; 2. Low/Medium defects, if still open, then are handled as a separate issue created in the Backlog, being handled independently as long as is not affecting the Acceptance Criteria of the original issue.
5. The user story has been approved by the product owner 1. PO approves and accepts the Acceptance Criteria; 2. If not then: Story is left Open OR A new independent issue is created and left in the backlog
6. PR is merged
Clone this wiki locally