generated from DSACMS/.github
-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
updated CONTRIBUTING.md based on repolinter
Signed-off-by: Natalia Luzuriaga <[email protected]>
- Loading branch information
1 parent
a33fd98
commit 080a7f9
Showing
1 changed file
with
58 additions
and
64 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,5 +1,3 @@ | ||
| <!--- # NOTE: Modify sections marked with `TODO` and then rename the file.--> | ||
|
|
||
| # How to Contribute | ||
|
|
||
| We're so thankful you're considering contributing to an [open source project of | ||
|
|
@@ -11,55 +9,83 @@ contributions. | |
| We encourage you to read this project's CONTRIBUTING policy (you are here), its | ||
| [LICENSE](LICENSE.md), and its [README](README.md). | ||
|
|
||
| ## Getting Started | ||
| <!--- ### TODO: If you have 'good-first-issue' or 'easy' labels for newcomers, mention them here.--> | ||
| ### Getting Started | ||
|
|
||
| To collect metrics, first make sure you have set the following environment variables: | ||
| - GITHUB_TOKEN - The github api key that you are using to collect data | ||
| - AUGUR_HOST - The api domain corresponding to an instance of [CHAOSS/Augur](https://github.com/chaoss/augur/) | ||
|
|
||
| Then, install the dependencies in requirements.txt. | ||
|
|
||
| Once the env is set up, either run the 'update data' GitHub Action in `.github/workflows/update_data.yml` or execute the `update.sh` shell script. | ||
|
|
||
| To run the server, make sure that your computer has npm installed. | ||
| Once npm is installed run `npm install` and `npm start` in the app/ directory. | ||
|
|
||
| ### Team Specific Guidelines | ||
| - Please try to keep pull requests to a reasonable size; try to split large contributions to multiple PRs | ||
| - Please create pull requests into dev unless the contribution is some kind of bugfix or urgent hotfix. | ||
| - Document and explain the contribution clearly according to provided standards when possible. | ||
| - Feel free to reach out to us if there is any confusion. | ||
|
|
||
| ### Building dependencies | ||
|
|
||
| <!--- ### TODO --> | ||
| 1. Clone the repo | ||
|
|
||
| `git clone https://github.com/DSACMS/metrics.git` | ||
|
|
||
| 2. Install the required packages in requirements.txt (preferably in a virtual env) | ||
|
|
||
| `pip3 install -r requirements.txt` | ||
|
|
||
| 3. Install node dependencies | ||
|
|
||
| `cd app && npm install && cd ..` | ||
|
|
||
| ### Building the Project | ||
|
|
||
| <!--- ### TODO --> | ||
| To collect metrics, first make sure you have set the following environment variables: | ||
| - GITHUB_TOKEN - The github api key that you are using to collect data | ||
| - AUGUR_HOST - The api domain corresponding to an instance of [CHAOSS/Augur](https://github.com/chaoss/augur/) | ||
|
|
||
| Once the env is set up, either run the 'update data' GitHub Action in `.github/workflows/update_data.yml` or execute the `update.sh` shell script. | ||
|
|
||
| To run the server, run `npm install` and `npm start` in the app/ directory. | ||
|
|
||
| ### Workflow and Branching | ||
|
|
||
| <!--- | ||
| TODO: Workflow Example | ||
| We follow the [GitHub Flow Workflow](https://guides.github.com/introduction/flow/) | ||
|
|
||
| 1. Fork the project | ||
| 1. Check out the `main` branch | ||
| 1. Create a feature branch | ||
| 1. Write code and tests for your change | ||
| 1. From your branch, make a pull request against `cmsgov/cmsgov-example-repo/main` | ||
| 1. Work with repo maintainers to get your change reviewed | ||
| 1. Wait for your change to be pulled into `cmsgov/cmsgov-example-repo/main` | ||
| 1. Delete your feature branch | ||
| --> | ||
| 2. Check out the `main` branch | ||
| 3. Create a feature branch | ||
| 4. Write code and tests for your change | ||
| 5. From your branch, make a pull request against `dev` if you have a feature change and `main` if it is a hotfix | ||
| 6. Work with repo maintainers to get your change reviewed and resolve git history if needed | ||
| 7. Wait for your change to be pulled into `dev` and later released into `main` | ||
| 8. Delete your feature branch | ||
|
|
||
| ### Testing Conventions | ||
|
|
||
| <!--- TODO --> | ||
| This project uses pytest as the main testing framework for the project's cli. | ||
|
|
||
| Python tests can be found in the `scripts/tests`. Any new testing | ||
| contributions are greatly appreciated and needed to ensure quality of any interpreted | ||
| language project. | ||
|
|
||
| ### Coding Style and Linters | ||
|
|
||
| <!--- TODO: Code Style Guide | ||
| This project adheres to PEP8 rules and guidelines whenever possible when accepting | ||
| new contributions of Python code. Although, there are good reasons to ignore particular guidelines | ||
| in particular situations. Further information on PEP8 can be found [here.](https://peps.python.org/pep-0008/) | ||
|
|
||
| 1. Mention any style guides you adhere to (e.g. pep8, etc...) | ||
| 1. Mention any linters your project uses (e.g. flake8, jslint, etc...) | ||
| 1. Mention any naming conventions your project uses (e.g. Semantic Versioning, CamelCasing, etc...) | ||
| 1. Mention any other content guidelines the project adheres to (e.g. plainlanguage.gov, etc...) | ||
| This project utilizes pylint as the primary linter for backend code, while eslint and prettier handle code formatting and linting for the frontend. Checks are implemented upon new pull requests into protected branches to ensure code quality and consistency. | ||
|
|
||
| --> | ||
| Python code quality checks are extremely useful for lowering the | ||
| cost of maintenence of Python projects. Further information on Pylint can be found [here.](https://pylint.readthedocs.io/en/latest/) | ||
|
|
||
| ### 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) | ||
|
|
@@ -77,12 +103,8 @@ When creating an issue please try to adhere to the following format: | |
| List all relevant steps to reproduce the observed behavior. | ||
|
|
||
| see our .github/ISSUE_TEMPLATE.md for more examples. | ||
| --> | ||
|
|
||
| ### Pull Requests | ||
|
|
||
| <!--- | ||
| ### TODO: Confirm | ||
| ### Writing Pull Requests | ||
|
|
||
| Comments should be formatted to a width no greater than 80 columns. | ||
|
|
||
|
|
@@ -118,13 +140,7 @@ Some important notes regarding the summary line: | |
| * 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. | ||
| --> | ||
|
|
||
| ## Code Review | ||
|
|
||
| <!--- | ||
| ### TODO: Code Review Example | ||
| ## Reviewing Pull Requests | ||
|
|
||
| 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 | ||
|
|
@@ -145,16 +161,10 @@ request will be closed. | |
| The changes in the pull request will be collapsed into a single commit, but the | ||
| authorship metadata will be preserved. | ||
|
|
||
| --> | ||
|
|
||
| ## Documentation | ||
|
|
||
| <!--- | ||
| ### TODO: Documentation Example | ||
| We also welcome improvements to the project documentation or to the existing | ||
| docs. Please file an [issue](https://github.com/cmsgov/cmsgov-example-repo/issues). | ||
| --> | ||
| docs. Please file an [issue](https://github.com/DSACMS/metrics/issues/new). | ||
|
|
||
| ## Policies | ||
|
|
||
|
|
@@ -166,32 +176,16 @@ questions, just [shoot us an email](mailto:[email protected]). | |
|
|
||
| ### Security and Responsible Disclosure Policy | ||
|
|
||
| The Centers for Medicare & Medicaid Services is committed to ensuring the | ||
| security of the American public by protecting their information from | ||
| unwarranted disclosure. We want security researchers to feel comfortable | ||
| reporting vulnerabilities they have discovered so we can fix them and keep our | ||
| users safe. We developed our disclosure policy to reflect our values and uphold | ||
| our sense of responsibility to security researchers who share their expertise | ||
| with us in good faith. | ||
|
|
||
| *Submit a vulnerability:* Unfortunately, we cannot accept secure submissions via | ||
| email or via GitHub Issues. Please use our website to submit vulnerabilities at | ||
| [https://hhs.responsibledisclosure.com](https://hhs.responsibledisclosure.com). | ||
| HHS maintains an acknowledgements page to recognize your efforts on behalf of | ||
| the American public, but you are also welcome to submit anonymously. | ||
|
|
||
| Review the HHS Disclosure Policy and websites in scope: | ||
| [https://www.hhs.gov/vulnerability-disclosure-policy/index.html](https://www.hhs.gov/vulnerability-disclosure-policy/index.html). | ||
|
|
||
| This policy describes *what systems and types of research* are covered under this | ||
| policy, *how to send* us vulnerability reports, and *how long* we ask security | ||
| researchers to wait before publicly disclosing vulnerabilities. | ||
|
|
||
| If you have other cybersecurity related questions, please contact us at | ||
| [[email protected]](mailto:[email protected]). | ||
| For more information about our Security, Vulnerability, and Responsible Disclosure Policies, see [SECURITY.md](SECURITY.md). | ||
|
|
||
| ## Public domain | ||
|
|
||
| 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/). | ||
| 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/) as indicated in [LICENSE](LICENSE). | ||
|
|
||
| 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. | ||
| 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. | ||