Skip to content

Before you start#

Thank you for your interest in contributing to the SCL Management!

The SCL is a highly ambitious project. It aims to satisfy demanding and moving customer requirements, which even includes BSI certification. The goals cannot be met without:

  1. common agreements about goals and derived strategies of the project in the form of specifications,
  2. ready knowledge of the agreements, and
  3. a critical mindset that continuously assesses the status quo and the impact of substantial changes with respect to the agreements.

General Development Guidelines#

Note

We (the SCL team) embrace an open, friendly, and cooperative work environment that is based on trust and everyone's own initiative.

These guidelines should serve as a general orientation how to work best in the project. We will not be over-pedantic with enforcing them, but please give these documents a quick read once in a while and try to adhere to them as much as possible.

  • First and foremost: Communication is key!
    • If there are any questions or anything is unclear, don't be afraid to ask.
    • If anything blocks you, tell us immediately.
    • If you see any potential issue or room for improvement, talk about it.
    • If there are discussion points or questions that you can contribute to, support the discussion.
    • Try to address communication prompts (requests for review, comments, etc.) very timely (e.g. same day or next work day).
    • All participants should try to keep the ball moving into the right direction and be the coworkers they would like to work with.
  • Strive for high quality, but do so pragmatically. Perfectionist is better than negligent, but Perfect is also the enemy of Done.
  • Inform yourself. Read and understand the available and relevant documentation and contained references before you start. Specifically, work through the list at the end of this document first. If anything is unclear, ask. Do not try to derive information by yourself if it is not 100% clear.
  • Document well so others can understand architecture and implementation decisions now and even in a couple of years. (See also the Contribution Workflow for more details.)
    • Write good Issues. Use our template. Try to answer all questions you would have yourself if you were not familiar with the gory details of the project. Document and discuss design concepts.
    • Write good Code. Your code should be as simple and self-documenting as possible.
    • Write good Commits. Commits should be atomic (change one thing, but all of it) and contain a good commit message, explaining the "What" and "Why".
    • Write good Merge Requests. Use our template and actively respond to comments during the review phase.
    • Write good Docs. Extend the relevant project documentation when adding new features or changing behavior.
  • Test well so you and others get immediate feedback when things get broken.

You can find more detailed and concrete guidelines in the Contribution Workflow document.