DEV Meeting 2

1) The meta and range library dependency

We will try to drop the dependency of both libraries by successively implementing what we need ourself.

• Try to avoid using the range library and instead use our views
• For ranges: Check whether the range you'd like to use is included in C++20. If the range IS going to be included, add it to our std header. If NOT, see the point before, or propose to implement it ourselves.

2) view::subrange(begin, end) vs. view::slice(pos, pos) vs std::span(begin, length)

Use std::span wherever you can (only works on container that are contiguous in memory, e.g. vector/array/string) because it has type erasure.

3) models vs satisfy

Please always use: a type models the concept.

4) East vs West Const/Constexpr

Please always use east const, e.g. int const myint{5}; Please always use west constexpr, e.g. constexpr int myint{5};

5) Commit message tagging

Please always label your commits with the following tags:

[FEATURE] Whenever you implement something new and shiny
[FIX]     Whenever you fix some wrong code in the source
[DOC]     Whenever you do something only(!) related to the documentation
[INFRA]   Whenever you change something of the build system or CI related
[TEST]    Whenever you do something related to the tests (unit or benchmark)
[MISC]    Whenever it does not fit to any of the above

If multiple tags would fit, you may separate them by comma, e.g. [INFRA,TEST] but always think about if it might be better to split up your commits (especially bigger ones).

Note: If splitting up commits, try to make sure that applying individual commits one after the other does not break the testing framework. This will be extremely helpful when searching for bugs in the code base later on (e.g. using git bisect).

6) Our new project management

You might have noticed that a lot of labels are gone. This is because we do want to keep stuff as simple as possible. We decided on the following this related to our issue/pr/review workflow:

• Labels: Are from now on used to label (external) issues into the following categories: feature-request, bug or user question. If your issue is just some task we decided for the sprint (e.g. name changes), there is no label needed. Two more labels are further available: You can still mark an issue as "good-first-issue" as this worked well so far. Additionally, there is a new label called "response-needed" which indicates that the external author of this issue needs to give us more information, until that happens, the issue is stalled. That's it, no other labels needed for now (except you can give a good reason for one). PR's are not labelled anymore.

• Projects: Instead of labelling, we will assign every issue and every PR to a Project! The project are mostly structured like our models so it should be easy to decide for a project.

• New ideas: If you have an idea or a point that needs to be discussed, do NOT open an issue for that from now on. Place ideas as cards into the respective project (with your name in case we want to get back to you for clarifying). If you have something, like a design decision, to be discussed, also open a card in the respective project and if it is urgent, come talk to one of the Core Developers. This will keep the issue list smaller.

• How to request reviews: 🔺 This is important because it is used the most but changes now! Please only request a review ONE AT A TIME and only in the end request a review of Hannes or Rene. This way, the current requested reviewer feels (hopefully) responsible of this pull request and respond more quickly. The review process will go back and forth (request vs WIP) until that person marks the changes as approved. Then you can request the next reviewer (2 are sufficient for small PRs). This will also help to keep a better overview over the comments and discussions.