templates: Create GitHub nomination template

---

name: Contributor Nomination

about: Nominate a GitHub user for additional rights on the Zephyr Project

title: ''

labels: Role Nomination

assignees: ''

---

# Background

The [TSC Project Roles] defines the main roles for the Zephyr Project, including

Maintainer, Collaborator, and Contributor.

By default anyone that contributes code or documentation is a Contributor, but

with the lowest [GitHub Permission Level] of Read. For example, Contributors

with Read permission do not have the permission to add reviewers to a pull

request.

Use this template to nominate a GitHub user for an elevated permission level in

the Contributor role.

# Nomination

## GitHub User

Provide the following information about the GitHub user:

1. Full Name

1. GitHub username

1. Organization (optional)

## Supporting Documents

Add links to 3-5 GitHub pull requests, in the Zephyr project, authored or

reviewed by the GitHub user that demonstrate the user's dedication to the

Zephyr project.

[TSC Project Roles]: <https://docs.zephyrproject.org/latest/development_process/project_roles.html#tsc-project-roles>

[GitHub Permission Level]: <https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization>

+++++++++++

A *Contributor* is a developer who wishes to contribute to the project,

at any level. Contributors who show dedication and skill are rewarded with

additional rights and responsibilities.

at any level.

Contributors are granted the following rights and responsibilities:

* Responsibility to follow the project’s code of conduct

  (https://github.com/zephyrproject-rtos/zephyr/blob/main/CODE_OF_CONDUCT.md)

Contributors are initially only given `Read

<https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization>`_

access to the Zephyr GitHub repository. Specifically, at the Read access level,

Contributors are not allowed to assign reviewers to their own pull requests. An

automated process will assign reviewers. You may also share the pull request on

the `Zephyr devel mailing list <https://lists.zephyrproject.org/g/devel>`_ or on

the `Zephyr Discord Server <https://chat.zephyrproject.org>`_.

Contributors who show dedication and skill are granted the Triage permission

level to the Zephyr GitHub repository.

You may nominate yourself, or another GitHub user, for promotion to the Triage

permission level by creating a GitHub issue, using the `nomination template

<https://github.com/zephyrproject-rtos/zephyr/issues/new?assignees=&labels=bug&template=nomination.md&title=>`_.

Contributors granted the Triage permission level are permitted to add reviewers

to a pull request and can be added as a reviewer by other GitHub users.

Contributor votes on pull requests are not counted with respect to accepting and

merging a pull request. However, Contributors comments and requested changes

should still be considered by the pull request author.

Collaborator

++++++++++++

* Responsibility to participate in the quality verification and release

  process, when those happen.

Contributors are promoted to the Collaborator role by adding the GitHub user

name to one or more ``collaborators`` sections of the :ref:`maintainers_file` in

the Zephyr repository.

Collaborator votes on pull requests can block or approve the pull request.

Maintainer

++++++++++

  within reasonable time.

* Responsibility to enforce the code of conduct.

Contributors or Collaborators are promoted to the Maintainer role by adding the

GitHub user name to one or more ``maintainers`` sections of the

:ref:`maintainers_file` in the Zephyr repository.

Maintainer votes on pull requests can block or approve the pull request.

Role Retirement

###############

Roles / Permissions

+++++++++++++++++++

.. table:: Project Roles vs Github Permissions

.. table:: Project Roles vs GitHub Permissions

    :widths: 20 20 10 10 10 10 10

    :align: center

    ================ =================== =========== ================ =========== =========== ============

.. _maintainers_file:

MAINTAINERS File

################

Generic guidelines for deciding and filling in the Maintainers' list

* The MAINTAINERS file shall replace the CODEOWNERS file and will be used

  for both setting assignees and reviewers.

* The :zephyr_file:`MAINTAINERS.yaml` file shall replace the

  :zephyr_file:`CODEOWNERS` file and will be used for both setting assignees and

  reviewers.

* We should keep the granularity of code maintainership at a manageable level

* We should be looking for maintainers for areas of code that

  are orphaned (i.e. without an explicit maintainer)

  * Un-maintained areas should be indicated clearly in the MAINTAINERS file

* All submitted pull-requests should have an assignee

* All submitted pull requests should have an assignee

* We Introduce an area/subsystem hierarchy to address the above point

  * Parent-area maintainer should be acting as default substitute/fallback

    assignee for un-maintained sub-areas

  * Area maintainer gets precedence over parent-area maintainer

* Pull-requests may be re-assigned if this is needed or more appropriate

* Pull requests may be re-assigned if this is needed or more appropriate

  * Re-assigned by original assignee (see “Assignee” slide)

  in a standalone commit alongside other changes introducing new files and

  directories to the tree.

* Major changes to the file, including the addition of new areas with new maintainers

  should come in as standalone pull-requests and require TSC review.

  should come in as standalone pull requests and require TSC review.

* If additional review by the TSC is required, the maintainers of the file

  should send the requested changes to the TSC and give members of the TSC two

  (2) days to object to any of the changes to maintainership of areas or the