# EditorConfig helps developers define and maintain consistent
# coding styles between different editors and IDEs
# editorconfig.org

root = true

[*]
# Change these settings to your own preference
indent_style = space
indent_size = 4

# We recommend you to keep these unchanged
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

# Markdown files sometimes need trailing whitespaces.

# You can define multiple automations in a .cm file, but each automation name should be unique
# within the file.  We keep each automation (or very closely related group of automations) in
# its own file.

on:
  - pr_created
  - commit
  - comment_added

automations:

  # If someone is a primary author of the files in a change, but NOT the pr author, automatically add them as a reviewer.

# You can define multiple automations in a .cm file, but each automation name should be unique
# within the file.  We keep each automation (or very closely related group of automations) in
# its own file.

on:
  - pr_created
  - commit
  - comment_added

automations:

  # If a PR contains non-trivial source changes and no tests, add a comment to the PR
  lacks_tests:
    if:

# You can define multiple automations in a .cm file, but each automation name should be unique
# within the file.  We keep each automation (or very closely related group of automations) in
# its own file.

on:
  - pr_created
  - commit
  - comment_added

automations:

  # If a PR is very complex, require 2 approvals
  complex_changes:
    if:

# You can define multiple automations in a .cm file, but each automation name should be unique
# within the file.  We keep each automation (or very closely related group of automations) in
# its own file.

on:
  - pr_created
  - commit
  - comment_added

automations:

  # Add a label that indicates how many minutes it will take to review the PR and categorizes it
  estimated_time_to_review:
    if:

# You can define multiple automations in a .cm file, but each automation name should be unique
# within the file.  We keep each automation (or very closely related group of automations) in
# its own file.

on:
  - pr_created
  - commit
  - comment_added

automations:

  # Label changes by affected platforms (in blue)
  {% for platform in platforms %}
  platform_label_{{ platform.name }}:
    if:

# You can define multiple automations in a .cm file, but each automation name should be unique
# within the file.  We keep each automation (or very closely related group of automations) in
# its own file.

on:
  - pr_created
  - commit
  - comment_added

automations:

  summary_table_platforms:
    if:
      - {{ ('summary_table_platforms' | isEnabledAutomation(pr)) }}
    run:

# You can define multiple automations in a .cm file, but each automation name should be unique
# within the file.  We keep each automation (or very closely related group of automations) in
# its own file.

on:
  - pr_created
  - commit

automations:

  # Add the a:documentation label to docs-only changes
  docs_only:
    if:
      - {{ ('misc_labels' | isEnabledAutomation(pr)) }}

# You can define multiple automations in a .cm file, but each automation name should be unique
# within the file.  We keep each automation (or very closely related group of automations) in
# its own file.

on:
  - pr_created
  - commit
  - comment_added

automations:

  # If someone adds a TODO, remind them about it by requesting removal
  includes_todos:
    if:

* To explain *rejected solutions*, for now, and future development, in case they are proposed again.

ADRs can be written by any team.
Like code, they should be reviewed by any other relevant teams.
The goal is not to *own* a decision, but to *share* it with other teams, and improve the build tool together.

### Format

The format for ADR should follow this template:

```markdown
# ADR-000X - Title

## Date

20YY-MM-DD