Start of development cycle 2023

[GoetzGoerisch]

Thank you @umati/maintainers for the yesterdays kick off meeting.
@Kantiran91 will compile Minutes of Meeting and the slides for our reference.

Meanwhile I took the liberty to update our project with iterations based on our yesterdays decision to go with 4 week sprints.
I assumed a start on Monday and assigned the tasks to the ISW colleagues as per there availablity of 20 days for the next iteration.
@Kantiran91 please review your work items and assign according your capacity.

Also as agreed yesterday all discussions shall take pleace here to overcome the Teams Tenant hurdles. Please adjust you GitHub Notification settings accordingly.

[Kantiran91]

Results of the dev Workshop (30-01-23)

slides can be found here vdw teams/umati.app

Workflow

• Regular sprints
  • 4 weeks cycle
  • Sprint planning
    • What is to be addressed?
    • Who is available?
    • how will it be implemented?
    • Preparation Goetz/Thomas
    • 9:00-11:00 Wednesday
  • Weekly (only with active developers) (20 min + blocker)
    • No substitute for short term coordination
    • Points for delays for joint team
    • 9:00-9:30 Tuesday
• Implementation chat for news / short term questions.
  • Switch to github team discussion
• Ticket system for "customer" requests
  • Own repo
  • Reference to umati.app on ticket system
  • Individual team members (Thomas/Götz) do 1-level support forward to specialists if necessary

Team Mindset

• New Features should have (Unit-)test (but not GUI testing)
• We document general stuff in a seperate Repos (@GoetzGoerisch You have a idea which repos?)
• Classes and method have a doxygen conform header comment
• We check in a PR if a Documentation of a Readme.md is needed
• We freeze Deps update before we have a fair
• We prefer sustainable solutions over short-term success
• If a special solution is needed this need to be discussed in the team
• We want to use types in Typescript (no any type)
• We inform the othe team member if we use the dev enviroment
• In Chat we prefer one message over n messages in a row
• We discuss problems direct at the code

Repos and Environment planing

• 3 enviroments (prod, dev, feature)
• prod = main branch
• dev = develop branch
• feature = feature branches

Rules for Pull Requests

• The following are the minimal requirements that every PR needs to meet.
• Pass Continuous Integration (CI): Every PR must pass our CI. This includes compilation with a range of compilers and for a range of target architectures, passing the unit tests and no detected issues with static code analysis tools.
• Signed CLA: Every contributor must sign the Contributor License Agreement (CLA) before we can merge his first PR. The signing can be done online. The link automatically appears on the page of the first PR. In addition, the CLA text can be accessed here.
• Separation of Concerns: Small changes are much easier to review. Typically, small PR are merged much faster. For larger contributions, it might make sense to break them up into a series of PR. For example, a PR with a new feature should not contain other commits with only stylistic improvements to another portion of the code.
• Feature Commits: The same holds true for the individual PR as well. Every commit inside the PR should do one thing only. If many changes have been applied at the same time, git add --patch can be used to partially stage and commit changes that belong together.
• Commit Messages: Good commit messages help in understanding changes. See the next section.
• Linear Commit History: Our goal is to maintain a linear commit history where possible. Use the git rebase functionality before pushing a PR. Use git rebase --interactive to squash bugfix commits.
• These labels can be used for the PR title to indicate its status.
  • [WIP]: The PR is work in progress and at this point simply informative.
• Feature-Branch Rebasing: Only the feature developer is allowed to rebase the feature branch of a PR

Commit and PR Hyiene

• We have very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history. But also, we use the git commit messages to generate the change log.
• This convention is identical to the Conventional Commits specification or the one used by Angular.
• Each commit message consists of a Header and optional a Body and a Footer. The header has a special format that includes a Type, a Scope and a Subject:
  <type>(<scope>): <subject>
• The Header is mandatory and the Scope of the header is optional.
• Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.
• The footer should contain a closing reference to an issue if any.
• Samples: (even more samples)
  • docs(server): add function documentation
  • fix(core): fix parsing of endpoint url
  • Parsing of endpoint urls now also supports https
• If the commit reverts a previous commit, it should begin with revert: , followed by the header of the reverted commit. In the body it should say: This reverts commit ., where the hash is the SHA of the commit being reverted.
• The commit Type Must be one of the following:
  • build: Changes that affect the build system or external dependencies
  • ci: Changes to our CI configuration files and scripts (example scopes: travis, appveyor, fuzz)
  • docs: Documentation only changes
  • feat: A new feature
  • fix: A bug fix
  • perf: A code change that improves performance
  • refactor: A code change that neither fixes a bug nor adds a feature
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • test: Adding missing tests or correcting existing tests

new Issues

• prepare a Test infrastrcture for all components
• create a documentation for local testing
• add class and methods comments for legacy code
• Create Document of all features
• Depoyment of the Dashboard for PRs
• Create a Architecture documentation
• Monitoring of all system components
• we add a vscode template in the doc repos