Repolinter Results

CODEOWNERS.md

@@ -17,3 +17,21 @@ Frontend
 
 # Questions?
 Email opensource@cms.hhs.gov
+
+# Code Owners 
+<!-- TODO: Who are the points of contact in your project who are responsible/accountable for the project? This can often be an engineering or design manager or leader, who may or may not be the primary maintainers of the project. List them by GitHub Username--> 
+
+ ## Repository Domains
+ <!--
+The Repo Domains section of your CODEOWNERS.md file helps manage code review responsibilities efficiently. Each domain represents a different aspect of the repository, such as documentation, frontend, backend, DevOps, testing, etc. In this section, list each domain and assign the appropriate GitHub usernames or teams responsible for that domain. This ensures that pull requests (PRs) are reviewed by the right experts, maintaining high code quality and relevance.
+For example:
+/docs/ @doc-team @johnsmith @janedoe
+/frontend/ @frontend-team @alice @bob
+/backend/ @backend-team @charlie @dana
+Furthermore, GitHub teams are a good feature for managing groups of contributors who need to be notified about specific domains within a repository. By creating and using GitHub teams, you can allow contributors to ping multiple relevant experts simultaneously.
+To set up GitHub teams:
+- Navigate to your organization's settings and select 'Teams'.
+- Create a new team for each domain, such as @frontend-team, @backend-team, or @doc-team.
+- Add the relevant members to each team. Ensure that the team includes all the individuals who should be notified about PRs in their domain.
+- When filling out the Repo Domains section in your CODEOWNERS.md file, use the team handles instead of or alongside individual usernames. This way, when a contributor opens a PR affecting a specific domain, they can simply tag the team, and every member of that team will be notified.
+--> 

CONTRIBUTING.md

@@ -189,3 +189,37 @@ For more information about our Security, Vulnerability, and Responsible Disclosu
 This project is in the public domain within the United States, and copyright and related rights in the work worldwide are waived through the [CC0 1.0 Universal public domain dedication](https://creativecommons.org/publicdomain/zero/1.0/).
 
 All contributions to this project will be released under the CC0 dedication. By submitting a pull request or issue, you are agreeing to comply with this waiver of copyright interest.
+
+ ### Building Dependencies 
+<!--- TODO: This step is often skipped, so don't forget to include the steps needed to install on your platform. If you project can be multi-platform, this is an excellent place for first time contributors to send patches!--> 
+
+ ### Writing Pull Requests 
+<!-- TODO: Make a brief statement about where to file pull/merge requests, and conventions for doing so. Link to PULL_REQUEST_TEMPLATE.md file.
+ Comments should be formatted to a width no greater than 80 columns.
+ Files should be exempt of trailing spaces.
+ We adhere to a specific format for commit messages. Please write your commit messages along these guidelines. Please keep the line width no greater than 80 columns (You can use `fmt -n -p -w 80` to accomplish this).
+ module-name: One line description of your change (less than 72 characters)
+ Problem
+ Explain the context and why you're making that change. What is the problem you're trying to solve? In some cases there is not a problem and this can be thought of being the motivation for your change.
+ Solution
+ Describe the modifications you've done.
+ Result
+ What will change as a result of your pull request? Note that sometimes this section is unnecessary because it is self-explanatory based on the solution.
+ Some important notes regarding the summary line:
+ workflows Describe what was done; not the result
+ workflows Use the active voice
+ workflows Use the present tense
+ workflows Capitalize properly
+ workflows Do not end in a period — this is a title/subject
+ workflows Prefix the subject with its scope
+ see our .github/PULL_REQUEST_TEMPLATE.md for more examples.
+ -->
+
+ ### Reviewing Pull Requests 
+<!--- TODO: Make a brief statement about how pull-requests are reviewed, and who is doing the reviewing. Linking to MAINTAINERS.md can help.
+ Code Review Example
+ The repository on GitHub is kept in sync with an internal repository at github.cms.gov. For the most part this process should be transparent to the project users, but it does have some implications for how pull requests are merged into the codebase.
+ When you submit a pull request on GitHub, it will be reviewed by the project community (both inside and outside of github.cms.gov), and once the changes are approved, your commits will be brought into github.cms.gov's internal system for additional testing. Once the changes are merged internally, they will be pushed back to GitHub with the next sync.
+ This process means that the pull request will not be merged in the usual way. Instead a member of the project team will post a message in the pull request thread when your changes have made their way back to GitHub, and the pull request will be closed.
+ The changes in the pull request will be collapsed into a single commit, but the authorship metadata will be preserved.
+ -->

MAINTAINERS.md

@@ -22,3 +22,7 @@ Reviewers:
 | reviewer     | review contributions from other members | history of review and authorship in a subproject | MAINTAINERS file reviewer entry, and GitHub Org Triage Team|
 | approver     | approve accepting contributions | highly experienced and active reviewer + contributor to a subproject  | MAINTAINERS file approver entry and GitHub Triage Team |
 | lead         | set direction and priorities for a subproject | demonstrated responsibility and excellent technical judgement for the subproject |  MAINTAINERS file owner entry and GitHub Org Admin Team|
+
+ ## Maintainers List: 
+<!-- TODO: What groups/domains are maintainers a part of? Does your project have domains/areas that are maintained by specific people? List @USERNAMES directly, or any @ALIASES for groups/teams. -->
+ -