Define Triager role (#357)

* Define triager role

* Update community-membership.md

Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>

* Remove comment about approvers being triagers

* Define where in git to list the triagers

* Clarify that triagers can be code commiters. Formatting.

* Add triager participation requirement

* approvers should be nested under triagers

* Update community-membership.md

* Update community-membership.md

Co-authored-by: Liz Fong-Jones <lizf@honeycomb.io>
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com>
Co-authored-by: Sergey Kanzhelev <S.Kanzhelev@live.com>

community-membership.md

@@ -93,6 +93,31 @@ code reviews and work towards becoming an *approver* for the subproject that
 they are active in.  Acceptance of code contributions requires at least one
 approver in addition to the reviews by *members.*
 
+## Triager
+
+Triagers assist the maintainers and approvers with project management and 
+backlog organization. The specific workflows and triage requirements depend on 
+the project, and are set by the project maintainers.
+
+Defined by: [Triage permissions](https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization#repository-access-for-each-permission-level), 
+with the names of the current Triagers commited to git, either in CONTRIBUTING, 
+CODEOWNERS, or the botom of the README.
+
+Triagers may be code contributors, but writing code is not a requirement for 
+becoming a triager. Triagers are encouraged to be active participants in project 
+meetings, chat rooms, and other discussion forums.
+
+### Requirements
+
+- Nominated by a maintainer, with no objections from other maintainers.
+- Consistently attend meetings and interact with issues for at least 1 month.
+
+### Responsibilities and privileges
+
+- Have an understanding of the goals and workflows defined by the maintainers.
+- Respond to new PRs and Issues by asking clarifying questions.
+- Organize the backlog by applying labels, milestones, assignees, and projects.
+
 ## Approver
 
 Code approvers are able to both review and approve code contributions, as well
@@ -107,8 +132,7 @@ Defined by: [CODEOWNERS
 workflow](https://help.github.com/en/articles/about-code-owners).
 
 Approver status can be scoped to a part of the codebase. For example, critical
-core components may have higher bar of becoming an approver. Some approvers may
-only be doing issues triage and have no approval rights.
+core components may have higher bar for becoming an approver.
 
 ### Requirements
 

docs/how-to-configure-new-repository.md

@@ -14,23 +14,22 @@ Documents [Community Membership](../community-membership.md) and
 [CONTRIBUTING](../CONTRIBUTING.md) define how permissions are typically set up
 for the repository.
 
-1. Every repository has two teams associated with it. Typically for the
-   repository `opentelemetry-foo` they will be named `foo-approvers` and
-   `foo-maintainers`. `foo-maintainers` is a child of `foo-approvers` as it
-   always contains subset of people and defines larger scope of privileges.
-2. Even though the members of `foo-maintainers` are included in `foo-approvers`
-   transitively, every member of `foo-maintainers` should be included in
-   `foo-approvers` explicitly, and with the "Maintainer" GitHub privileges. So
-   repository maintainers can invite new approvers to the team.
-3. The team `foo-approvers` has `Write` permissions for the repository.
-4. The team `foo-maintainers` has `Maintain (beta)` permissions for the
+1. Every repository has three teams associated with it. Typically for the
+   repository `opentelemetry-foo` they will be named `foo-triagers`, `foo-approvers`,
+   and `foo-maintainers`. `foo-maintainers` is a child of `foo-approvers`, and 
+   `foo-approvers` is a child of `foo-triagers`, as it each group always contains 
+   a subset of people and defines a larger scope of privileges.
+2. Every member of `foo-maintainers` should be included in
+   `foo-approvers` and `foo-triagers` explicitly, with the "Maintainer" GitHub 
+   privileges. This allows repository maintainers to invite new approvers and 
+   triagers to the team.
+3. The team `foo-triagers` has `Triage` permissions for the repository.
+4. The team `foo-approvers` has `Write` permissions for the repository.
+5. The team `foo-maintainers` has `Maintain (beta)` permissions for the
    repository.
-5. Root-level `CODEOWNERS` file on the repository should include superset of
-   people from both teams.
-6. Every repository has Admins group defined as Admins for the repository.
-7. Some repositories may include more individuals outside of approvers and
-   maintainers teams with the `Write` permissions. Typically for issues tracking
-   and triage purpose.
+6. Root-level `CODEOWNERS` file on the repository should include superset of
+   people from both `foo-approvers` and `foo-maintainers`.
+7. Every repository has Admins group defined as Admins for the repository.
 8. Some repositories may include more individuals with `Admin` permissions.
    Typically to help set up repository, CI, web hooks or other administrative
    work.