Added docs explaining CMS code.json

.github/ISSUE_TEMPLATE/metadata-field-addition.md

@@ -0,0 +1,28 @@
+---
+name: Metadata Field Addition
+about: Suggest a field to add to code.json schema
+title: "[METADATA]"
+labels: schema
+assignees: natalialuzuriaga
+---
+
+## Issue Report - Metadata
+
+module-name: One line summary of the issue (less than 72 characters)
+
+### Proposed Field information
+
+Fill out the information below on the new proposed field. Please refer to the structure of the code.json fields found here: https://github.com/DSACMS/gov-codejson/blob/main/schemas/schema-0.1.0.json
+
+```
+"key-name-here": {
+                "type": "____",
+                "description": "One liner describing new field here"
+            },
+```
+
+Provide example values here:
+
+### Explanation
+
+Describe more about the new field to add to code.json. Provide an explanation of why this field should be included and how its collection provides value to the agency.

CODEOWNERS.md

@@ -1,33 +1,9 @@
 # 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-->
 
 - @natalialuzuriaga
--  @decause-gov
-
+- @decause-gov
 
 ## Repo 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.
-
--->
-
-/docs/ {Git usernames of documentation owners}  
-/frontend/ {Git usernames of frontend owners}
+/docs @natalialuzuriaga @decause-gov @sachin-panayil
+/schema/ @natalialuzuriaga @decause-gov

CONTRIBUTING.md

@@ -1,9 +1,5 @@
-<!--- # NOTE: Modify sections marked with `TODO` -->
-
 # How to Contribute
 
-<!-- Basic instructions about where to send patches, check out source code, and get development support.-->
-
 We're so thankful you're considering contributing to an [open source project of
 the U.S. government](https://code.gov/)! If you're unsure about anything, just
 ask -- or submit the issue or pull request anyway. The worst that can happen is
@@ -15,77 +11,51 @@ We encourage you to read this project's CONTRIBUTING policy (you are here), its
 
 ## Getting Started
 
-<!--- TODO: If you have 'good-first-issue' or 'easy' labels for newcomers, mention them here.-->
+If you would like to comment and provide feedback on the metadata standard, please let us know by filing an **issue on our GitHub repository.**
+
+We are open to adding more fields to CMS code.json for any metadata the agency sees value in collecting. Request new metadata fields by filing a metadata field addition issue [here](https://github.com/DSACMS/gov-codejson/issues/new?template=metadata-field-addition.md).
 
 ### Team Specific Guidelines
 
-<!-- TODO: This section helps contributors understand any team structure in the project (formal or informal.) Encouraged to point towards the MAINTAINERS.md file for further details.-->
+The project is led by the CMS Open Source Program Office team as detailed in [MAINTAINERS.md](/MAINTAINERS.md)
 
 ### 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!-->
+N/A
 
 ### Building the Project
 
-<!--- TODO: Be sure to include build scripts and instructions, not just the source code itself! -->
+N/A
 
 ### Workflow and Branching
 
-<!--- TODO: Workflow Example
 We follow the [GitHub Flow Workflow](https://guides.github.com/introduction/flow/)
 
 1.  Fork the project
 2.  Check out the `main` branch
 3.  Create a feature branch
-4.  Write code and tests for your change
+4.  Write changes
 5.  From your branch, make a pull request against `DSACMS/gov-codejson/main`
 6.  Work with repo maintainers to get your change reviewed
 7.  Wait for your change to be pulled into `DSACMS/gov-codejson/main`
 8.  Delete your feature branch
--->
 
 ### Testing Conventions
 
-<!--- TODO: Discuss where tests can be found, how they are run, and what kind of tests/coverage strategy and goals the project has. -->
+N/A
 
 ### Coding Style and Linters
 
-<!--- TODO: HIGHLY ENCOURAGED. Specific tools will vary between different languages/frameworks (e.g. Black for python, eslint for JavaScript, etc...)
-
-1. Mention any style guides you adhere to (e.g. pep8, etc...)
-2. Mention any linters your project uses (e.g. flake8, jslint, etc...)
-3. Mention any naming conventions your project uses (e.g. Semantic Versioning, CamelCasing, etc...)
-4. Mention any other content guidelines the project adheres to (e.g. plainlanguage.gov, etc...)
-
--->
+N/A
 
 ### Writing Issues
 
-<!--- TODO: Example Issue Guides
-
-When creating an issue please try to adhere to the following format:
-
-    module-name: One line summary of the issue (less than 72 characters)
-
-    ### Expected behavior
-
-    As concisely as possible, describe the expected behavior.
-
-    ### Actual behavior
-
-    As concisely as possible, describe the observed behavior.
-
-    ### Steps to reproduce the behavior
+If you would like to comment on the metadata standard, please let us know by filing an **issue on our GitHub repository.**
 
-    List all relevant steps to reproduce the observed behavior.
-
-    see our .github/ISSUE_TEMPLATE.md for more examples.
--->
+We are open to adding more fields to CMS code.json for any metadata the agency sees value in collecting. Request new metadata fields by filing a metadata field addition issue [here](https://github.com/DSACMS/gov-codejson/issues/new?template=metadata-field-addition.md).
 
 ### 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.
@@ -113,56 +83,26 @@ columns (You can use `fmt -n -p -w 80` to accomplish this).
 
 Some important notes regarding the summary line:
 
-* Describe what was done; not the result
-* Use the active voice
-* Use the present tense
-* Capitalize properly
-* Do not end in a period — this is a title/subject
-* Prefix the subject with its scope
-
-    see our .github/PULL_REQUEST_TEMPLATE.md for more examples.
--->
+- Describe what was done; not the result
+- Use the active voice
+- Use the present tense
+- Capitalize properly
+- Do not end in a period — this is a title/subject
+- Prefix the subject with its scope
 
 ## 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.
-
--->
+Pull requests will be reviewed by the CMS Open Source Program Office team as detailed in [MAINTAINERS.md](/MAINTAINERS.md)
 
 <!--
 ## Shipping Releases
 
-<!-- TODO: What cadence does your project ship new releases? (e.g. one-time, ad-hoc, periodically, upon merge of new patches) Who does so? 
+<!-- TODO: What cadence does your project ship new releases? (e.g. one-time, ad-hoc, periodically, upon merge of new patches) Who does so?
 -->
 
 ## Documentation
 
-<!-- TODO: Documentation Example
-
-We also welcome improvements to the project documentation or to the existing
-docs. Please file an [issue](https://github.com/DSACMS/gov-codejson/issues).
--->
+Refer to [/docs](./docs/) for information about CMS code.json metadata standard.
 
 ## Policies
 
@@ -174,7 +114,7 @@ questions, just [shoot us an email](mailto:[email protected]).
 
 ### Security and Responsible Disclosure Policy
 
-*Submit a vulnerability:* Vulnerability reports can be submitted through [Bugcrowd](https://bugcrowd.com/cms-vdp). Reports may be submitted anonymously. If you share contact information, we will acknowledge receipt of your report within 3 business days.
+_Submit a vulnerability:_ Vulnerability reports can be submitted through [Bugcrowd](https://bugcrowd.com/cms-vdp). Reports may be submitted anonymously. If you share contact information, we will acknowledge receipt of your report within 3 business days.
 
 For more information about our Security, Vulnerability, and Responsible Disclosure Policies, see [SECURITY.md](SECURITY.md).