Add Common Repository Structure policy

Signed-off-by: Tracy Kuhrt <tracy.a.kuhrt@accenture.com>

tac/governing-documents/MAINTAINERS-file.md

@@ -0,0 +1,120 @@
+---
+layout: default
+title: MAINTAINERS Guidelines
+parent: Governing Documents
+grand_parent: LF Decentralized Trust TAC
+nav_order: 2
+---
+[//]: # (SPDX-License-Identifier: CC-BY-4.0)
+
+## Introduction
+
+All LF Decentralized Trust (LFDT) repositories **MUST** have a `MAINTAINERS.md` file at the top-level directory of the source code. The [SAMPLE-MAINTAINERS.md](./SAMPLE-MAINTAINERS) can be used as a template by projects creating a new repository.
+
+The Technical Steering Committee (TSC) for the project to which a repository belongs **MUST** periodically send out notifications about missing `MAINTAINERS.md` files.
+
+The LFDT GitHub organization administrators (i.e., LFDT TAC) **SHOULD** periodically send out notifications about missing `MAINTAINERS.md` files.
+
+The following provides guidelines and suggested content to include in the `MAINTAINERS.md` file.
+
+## Maintainer Scopes and GitHub Roles
+
+Becoming a Maintainer for a repository implies being granted special privileges
+within that repository to do the additional scope(s) of work required of a
+Maintainer. In most cases, the additional privileges are implemented by giving
+maintainers one of the elevated [GitHub
+roles](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/repository-roles-for-an-organization)
+within the repository.
+
+In most repositories, the "Maintainer" scope is given to all repository
+Maintainers. The "Maintainer" scope is defined as the "Maintain" GitHub role.
+This is usually sufficient to do all of the work required of a Maintainer. From
+time to time, Maintainers may have to request certain administrative tasks by
+performed by the LFDT GitHub organization administrators.
+
+In some repositories, the maintainers may decide to define additional scopes and
+each Maintainer given one or more of those designated scopes:
+
+- In rare cases, Maintainers in a repository may request that the project's TSC enable designating some Maintainers with different GitHub roles, such as "Admin" (more capable than "Maintain") or "Triage" (less capable than "Maintain").
+  - Each elevated GitHub role needed in a repository requires the project's TSC to create and maintain an additional GitHub Team.
+  - The LFDT TAC manages a team per LFDT Project that includes all contributors to the project. That team is given the "Read" GitHub role in all project repositories. This team need not be documented in the "MAINTAINERS" file.
+- Maintainers **MAY** define Maintainer scopes within a repository that don't require
+  elevated GitHub privileges. For example, a scope might include hosting
+  community meetings, or contributing to the LFDT Project's Quarterly
+  report.
+
+If there is more than the single "Maintainer" scope used in a repository, there **MUST** be a list of the repository specific scopes in the MAINTAINERS file. The list must include the scope name, the definition of the scope, and if applicable, the related GitHub Role and Team for the scope.
+
+| Scope      | Definition               | GitHub Role | GitHub Team               |
+| ---------- | ------------------------ | ----------- | ------------------------- |
+| Maintainer | The GitHub Maintain role | Maintain    | `<repository> committers` |
+
+## List of Repository Maintainers
+
+Lists of active and emeritus maintainers **MUST** be included in the `MAINTAINERS.md` file.
+
+Changes to the maintainers lists **MUST** be made via Pull Requests. Once a new `MAINTAINERS.md` file is created or a PR changing the maintainer lists within the file is merged, a corresponding update to the affected GitHub Teams within the LFDT GitHub organization must be made. This is a manual process and the maintainers must ensure that it occurs.
+
+It is recommended that the lists be sorted alphabetically and **MUST** contain at least the Maintainers name, GitHub ID, Scope, and at least one contact method. The reasons for populating columns are:
+
+- A GitHub ID **MUST** be provided to add the Maintainer to a GitHub Team, and to recognize the action the Maintainer takes in the repository.
+- The Scope **MUST** be provided to know the role of each Maintainer, and to know the GitHub Team to update when adding/removing Maintainers.
+- A LFID (Linux Foundation ID), Discord ID and/or Email are the most effective ways for the LFDT to contact the Maintainer when necessary.
+- A Company Affiliation is helpful for monitoring the diversity of the Maintainer community for a project.
+
+The following table format **MUST** be used for both Maintainers lists (active and emeritus):
+
+**Active Maintainers**
+
+| Name | GitHub ID | Scope | LFID | Discord ID | Email | Company Affiliation |
+| ---- | --------- | ----- | ---- | ---------- | ----- | ------------------- |
+|      |           |       |      |            |       |                     |
+
+**Emeritus Maintainers**
+
+| Name | GitHub ID | Scope | LFID | Discord ID | Email | Company Affiliation |
+| ---- | --------- | ----- | ---- | ---------- | ----- | ------------------- |
+|      |           |       |      |            |       |                     |
+
+## Maintainer Duties
+
+The `MAINTAINERS.md` file **SHOULD** contain information about the different
+maintainer scopes, and for each, the maintainers duties (e.g., maintainers
+calls, quarterly reports, code reviews, issue cleansing). See the [Sample
+Maintainers](./SAMPLE-MAINTAINERS) for an example of what to include in this
+section for an open source software project. Feel free to evolve that text to
+match the needs of the repository and project.
+
+If the repository is for a community specification, or other governance or
+documentation purpose, the tasks of the Maintainers (often called "Editors"
+in such cases) might be different than for Maintainers of an open source code
+project. The Maintainer role is more about approving and merging pull requests
+that reflect the agreement of the community, as opposed to code related metrics
+(quality, fit for purpose, tests, etc.). In some cases, a GOVERNANCE.md file
+like the [AnonCreds Methods Registry governance file] might further define the duties of the maintainers.
+
+[AnonCreds Methods Registry governance file]: https://github.com/hyperledger/anoncreds-methods-registry/blob/main/registry/governance.md
+
+## How to Become a Maintainer
+
+The `MAINTAINERS.md` file **SHOULD** contain information about how to become a
+maintainer for the project. This section **SHOULD** list specific information
+about what is required. Information that **SHOULD** be included in this section:
+
+* What is required before someone can be considered to become a maintainer.
+  * Include a statement on how an emeritus maintainer can be changed to active again.
+* Consider whether there should be different requirements based on the scope of a given maintainer.
+* Whether sponsorship by an existing maintainer is required.
+* How maintainers are proposed to the community. Proposals are typically done by creating PR against the `MAINTAINERS.md` file, and including information in the PR about how the proposed contributor meets the criteria to be a maintainer.
+* How many maintainers must approve the proposed maintainer.
+* How long the existing maintainers have to respond to the proposal.
+
+## How Maintainers are Removed or Moved to Emeritus Status
+
+The `MAINTAINERS.md` file **SHOULD** contain information about how a maintainer is removed from the list of active maintainers. Information that **SHOULD** be included in this section:
+
+* The reasons a maintainer would be removed from the list of active maintainers.
+* How a removal is proposed. Typically, this is similar to the way in which maintainers are added, such as via a PR against the `MAINTAINERS.md` file.
+
+# References
+* [TAC Decision Log - Common Maintainers Management Policy](https://wiki.hyperledger.org/display/TSC/Common+Maintainers+management+policy)

tac/governing-documents/SAMPLE-MAINTAINERS.md

@@ -0,0 +1,117 @@
+---
+layout: default
+title: Sample MAINTAINERS file
+nav_exclude: true
+---
+[//]: # remove this line, and all prior, before using in a repo.
+[//]: # (SPDX-License-Identifier: CC-BY-4.0)
+# Maintainers
+
+This is a sample `MAINTAINERS.md` file for a LF Decentralized Trust (LFDT) project repository.
+Feel free to copy this file into your repository and update it for your specific
+needs.
+
+It is sufficient to have a `MAINTAINERS.md` file that contains only a reference to a `MAINTAINERS.md` file in another repository that is part of the LFDT project.  For example:
+
+> For information about the Maintainers of this repository, please see this \<PROJECT> repository's [MAINTAINERS](#) file.
+
+## Maintainer Scopes, GitHub Roles and GitHub Teams
+
+Maintainers are assigned the following scopes in this repository:
+
+| Scope | Definition | GitHub Role | GitHub Team |
+| ----- | ---------- | ----------- | ----------- |
+| Maintainer | The GitHub Maintain role | Maintain   | `<repository> committers`     |
+
+## Active Maintainers
+
+<!-- Please keep this sorted alphabetically by github -->
+
+| Name | GitHub ID | Scope | LFID | Discord ID | Email | Company Affiliation |
+|----- | --------- | ----- | ---- | ---------- | ----- | ------------------- |
+|      |           |       |      |            |       |                     |
+
+
+## Emeritus Maintainers
+
+| Name | GitHub ID | Scope | LFID | Discord ID | Email | Company Affiliation |
+|----- | --------- | ----- | ---- | ---------- | ----- | ------------------- |
+|      |           |       |      |            |       |                     |
+
+## The Duties of a Maintainer
+
+Maintainers are expected to perform the following duties for this repository. The duties are listed in more or less priority order:
+
+- Review, respond, and act on any security vulnerabilities reported against the repository.
+- Review, provide feedback on, and merge or reject GitHub Pull Requests from
+  Contributors.
+- Review, triage, comment on, and close GitHub Issues
+  submitted by Contributors.
+- When appropriate, lead/facilitate architectural discussions in the community.
+- When appropriate, lead/facilitate the creation of a product roadmap.
+- Create, clarify, and label issues to be worked on by Contributors.
+- Ensure that there is a well defined (and ideally automated) product test and
+  release pipeline, including the publication of release artifacts.
+- When appropriate, execute the product release process.
+- Maintain the repository CONTRIBUTING.md file and getting started documents to
+  give guidance and encouragement to those wanting to contribute to the product, and those wanting to become maintainers.
+- Contribute to the product via GitHub Pull Requests.
+- Monitor requests from the LF Decentralized Trust Technical Advisory Council about the
+contents and management of LFDT repositories, such as branch handling,
+required files in repositories and so on.
+- Contribute to the LFDT Project's Quarterly Report.
+
+## Becoming a Maintainer
+
+This community welcomes contributions. Interested contributors are encouraged to
+progress to become maintainers. To become a maintainer the following steps
+occur, roughly in order.
+
+- The proposed maintainer establishes their reputation in the community,
+  including authoring five (5) significant merged pull requests, and expresses
+  an interest in becoming a maintainer for the repository.
+- A PR is created to update this file to add the proposed maintainer to the list of active maintainers.
+- The PR is authored by an existing maintainer or has a comment on the PR from an existing maintainer supporting the proposal.
+- The PR is authored by the proposed maintainer or has a comment on the PR from the proposed maintainer confirming their interest in being a maintainer.
+  - The PR or comment from the proposed maintainer must include their
+    willingness to be a long-term (more than 6 month) maintainer.
+- Once the PR and necessary comments have been received, an approval timeframe begins.
+- The PR **MUST** be communicated on all appropriate communication channels, including relevant community calls, chat channels and mailing lists. Comments of support from the community are welcome.
+- The PR is merged and the proposed maintainer becomes a maintainer if either:
+  - Two weeks have passed since at least three (3) Maintainer PR approvals have been recorded, OR
+  - An absolute majority of maintainers have approved the PR.
+- If the PR does not get the requisite PR approvals, it may be closed.
+- Once the add maintainer PR has been merged, any necessary updates to the GitHub Teams are made.
+
+## Removing Maintainers
+
+Being a maintainer is not a status symbol or a title to be carried
+indefinitely. It will occasionally be necessary and appropriate to move a
+maintainer to emeritus status. This can occur in the following situations:
+
+- Resignation of a maintainer.
+- Violation of the Code of Conduct warranting removal.
+- Inactivity.
+  - A general measure of inactivity will be no commits or code review comments
+    for one reporting quarter. This will not be strictly enforced if
+    the maintainer expresses a reasonable intent to continue contributing.
+  - Reasonable exceptions to inactivity will be granted for known long term
+    leave such as parental leave and medical leave.
+- Other circumstances at the discretion of the other Maintainers.
+
+The process to move a maintainer from active to emeritus status is comparable to the process for adding a maintainer, outlined above. In the case of voluntary
+resignation, the Pull Request can be merged following a maintainer PR approval. If the removal is for any other reason, the following steps **SHOULD** be followed:
+
+- A PR is created to update this file to move the maintainer to the list of emeritus maintainers.
+- The PR is authored by, or has a comment supporting the proposal from, an existing maintainer or a member of the project's Technical Steering Commitee (TSC).
+- Once the PR and necessary comments have been received, the approval timeframe begins.
+- The PR **MAY** be communicated on appropriate communication channels, including relevant community calls, chat channels and mailing lists.
+- The PR is merged and the maintainer transitions to maintainer emeritus if:
+  - The PR is approved by the maintainer to be transitioned, OR
+  - Two weeks have passed since at least three (3) Maintainer PR approvals have been recorded, OR
+  - An absolute majority of maintainers have approved the PR.
+- If the PR does not get the requisite PR approvals, it may be closed.
+
+Returning to active status from emeritus status uses the same steps as adding a
+new maintainer. Note that the emeritus maintainer already has the 5 required
+significant changes as there is no contribution time horizon for those.

tac/governing-documents/repository-structure.md

@@ -31,7 +31,7 @@ format suffixes such as `.md`, `.rst`, or `.txt`.
     -   The current and important past releases
     -   Documentation for developers and users
 -   `MAINTAINERS` \
-    A list of all current maintainers with contact info. [A separate document](MAINTAINERS-file.md)
+    A list of all current maintainers with contact info. [A separate document](./MAINTAINERS-file)
     covers the specifics.
 -   `CONTRIBUTING` \
     Directions on how to contribute code to the project, or a pointer to that information.