🏷️ Special PR & issue labels

We have a few special Tags on our Issues and Pull-Requests in Github. This tries to explain them to the extend they are useful.

General Tags

Tag-Prefixes

We have a list of prefixes for certain tags that share a common "category" of some sort. They usually also have the exact same color to keep them visibly distinct.

• c- (like c-avatar or c-super-invites) indicate that this issue/PR belongs to a specific "component" of the application, e.g. a plugin or package we have
• ci- (like ci-test-ui-test-all) indicate Github workflow specific tags (see below), mostly for PRs
• f- (like f-attachments) are indicating that this is about a specific app-wide feature
• needs (like needs input, needs investigation, needs design) indicate that this issue is stalled because of external requirements that need to be met
• s- (like s-news, s-chat) indicate this issue is about a specific section
• t- (like t-desktop) indicate this issue/PR is about a specific target platform

Informational

Some labels are purely to convey some simple information, like

• help wanted and good first issue mark issues that are written up enough for any contributor to take them on
• flutter, dart and rust imply that the content is only containing this type of code (which is useful for reviewers if they are only knowledgeable in certain areas)
• documentation, dependencies, translations, github_actions indicate that the given issue PR is only about the indicated thing, e.g. an update of translation, documentation or dependencies without any further code changes.
• tracking this is a tracking issue on a specific subject, collecting other issues under a common umbrella
• tech-debt this issue describes tech debt we have bought on and need to be dealt with at some point
• bug is just the indicator that this is a bug
• piloting indicates this came up in a piloting or onboarding call
• smooth UX, privacy & security, e2ee and infrastructure indicate this issue is of certain importance in relation to the given subject

Procedural tags

We have a few tags that we use to convey important information about the process of this PR.

• minor by default all PRs need a reviewer to sign-off before merging. Sometimes that procedure is overkill and just slows down the process for minor things. If the thing is really just a small patch, you have commit rights to the repo and you are willing to take over all responsibility for it you can mark them with the minor tag and push the auto merge button right after. You can also still indicate reviewers but you should be clear whether you will be waiting for their review or not in the description or comment
• merge post release only quite the opposite of minor this indicates you are doing a significant change that you want to have on nightly a few days before sending it out to the weekly release. PRs marked with this may only be merged from Thursday (after the release has been cut) until Monday (before the Tuesday nightly will be cut) to give us at least two nightly cycles to play with it.

CI control

We have several tags that control what the CI does on a specific PR.

• build-demo tells the CI that the author wants demo builds of the App for the given PR. This is only possible if the PR is on a demo--prefixed-branch on the main repo (due to the need to access repo specific secrets). But these constraints are met every push the CI will attempt to build the demo release version of the App and post the link to the assets as comment.
  This is very helpful if you need to test that the changes given do not break the final built.
• (in progress) Running the entire end-to-end-test integration test suite of the app is costly - in both times and resources. So we are not running it on every PR. But if you want your PR to be checked with it you can add ci-test-ui-all and the CI will run the test suite against your PR. We usually only run this after every merge.
  UI Tests don't currently run on CI... see this issue