First commit

Your first commit to this repository is deliberately not a solution to a challenge. It is a registration commit. The commit must contain two short files:

1. Your entry in .mailmap. Put the entry in alphabetical order.
2. A new file users/<assigned-nickname>.yml. This file records the start of the Fluid Attacks Academy phase that you enter.

The two files must be in the same commit. Record only your current phase. You add a new period entry later, if you move to a different phase.

After the reviewer merges this commit, send your first solution in a separate merge request. Use the regular submission procedure.

Reason

The .mailmap entry gives you one authorship identity in the repository. All your commits then resolve to the same talent, even when your name or your email address changes.

The users/<assigned-nickname>.yml file gives you a phase timeline. The CI uses these timestamps to compute Time-to-First-Solution and the other metrics that start at a phase. Without the file, the CI anchors your solutions to the moment of your first push. That moment is later than your true start, so the metrics then show a cycle time that is too short.

The two files together keep the registration simple: one commit, one merge request, and no challenge content.

YAML format

users/<assigned-nickname>.yml is a file in the users/ folder at the root of the repository. The filename is in kebab case. The Academy team gives you the <assigned-nickname> alias, for example efficient-cottage or bright-spark.

Record only the phase that you start with. Add a new period entry later, if you move to the next phase. Therefore the file is short, and it usually has one entry. The file becomes longer as you move through the phases.

This example shows a full-time talent who starts in onboarding:

user:
  dedication: full-time
  periods:
    - type: onboarding
      start: "2026-03-19T01:07:57Z"

This example shows a part-time talent who starts in practice:

user:
  dedication: part-time
  periods:
    - type: practice
      start: "2026-05-10T08:00:00Z"

Schema rules:

• user.dedication gives your weekly commitment. The accepted values are full-time (42 h/week) and part-time (21 h/week). The CI uses this value to compute the workload percentage on the Active Users dashboard. Terms is the source of these hours. The schema accepts a file with no dedication, and then it reads full-time. Write the field anyway. Without it, the CI measures a part-time talent against 42 h/week.
• user.absences is an optional list of justified absences. Each entry has type, start and end. The two timestamps are in ISO 8601 format with a timezone. The accepted types are bereavement-leave, paid-leave, vacation, public-holiday, jury-duty, medical-leave and personal-absence. The CI removes the weekdays of each absence from the denominator of the workload metric. The CI discounts the Colombian public holidays automatically, so do not list them here. The reviewer maintains this field, not the talent.
• user.periods is a list, and the list must not be empty. Each entry has type and start, and it accepts an optional end.
• type is one of the four current Academy phases: journey, quest, onboarding or practice. Each phase is a correct first phase. A new employee usually starts in onboarding and then moves to practice. An employee who completed onboarding in a previous process starts directly in practice. An external talent starts in journey or in quest.
• start is an ISO 8601 timestamp with a timezone. The canonical form ends with Z for UTC. An explicit offset such as -05:00 is also correct. You can give sub-second precision, and minute precision is sufficient when you do not know the exact time. The CI rejects a timestamp without a timezone, because such a timestamp causes timezone comparison errors.
• end closes the phase. It is an ISO 8601 timestamp with a timezone, and it must be later than the start of the same entry. A phase with no end stays open. The start of the next phase closes it, and the last phase with no end is your current phase. The Academy team maintains this field, not the talent, so your registration commit gives only type and start.
• The periods must be in chronological order. Each start must be equal to the previous start or later than it.
• The file must contain the user key and nothing else. The CI rejects any other key at the top of the file.

Git and mailmap

Before your first commit, configure git with your name and your email. Use the corporate email account of your GitLab account. Getting started gives the rule of the account. This is an example:

git config --global user.name "John Doe"
git config --global user.email "[email protected]"

Then add the same credentials to the .mailmap file in the root folder of the repository. Keep the file in alphabetical order.

John Doe <[email protected]> GitlabUsername <[email protected]>

Then run the test nix run .#lint-git-mailmap. Local builds tells you how to run the local checks.

Commit message

The first commit is not a chall\sol commit. It uses the common product, the chore type and the conf scope. This combination is for registration commits that apply to the full repository and not to one product.

common\chore(conf): #0 first commit

- register <assigned-nickname>

Replace <assigned-nickname> with the alias that the Academy team gives you. This alias is also the filename of your users/<assigned-nickname>.yml file.

CI checks

• lint-git-mailmap verifies that your .mailmap entry is in alphabetical order and has the correct format.
• test-users-yaml verifies your users/<assigned-nickname>.yml file against the Pydantic schema. It checks the phase types, the timestamps and the chronological order.

If one of these jobs fails, correct the file, amend the commit and push again.

Review

When a talent is not yet in .mailmap, the reviewer verifies the first merge request:

• The merge request contains the .mailmap entry and the users/<assigned-nickname>.yml file, and no other file.
• The merge request contains no solution. Solutions go in a separate merge request, after the reviewer merges this one.
• The filename matches the assigned nickname of the talent.
• The phase types and the start timestamps are reasonable for the phase that the talent announced.