From 09055da211701d566d0ec5eca1293e9c44249073 Mon Sep 17 00:00:00 2001 From: Mint Thompson Date: Thu, 13 Jun 2024 11:20:33 -0400 Subject: [PATCH 1/5] Add security policy (#24) Security policy includes instructions for reporting security issues privately and project security practices. --- SECURITY.md | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 SECURITY.md diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..a172109 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,9 @@ +# Reporting security issues privately + +To report a security issue privately, please [create a security advisory](https://github.com/standardhealth/fhir-package-loader/security/advisories) in this repository. This will allow repository administrators to review and address it privately before public disclosure. For more details about this process, see ["Privately reporting a security vulnerability"](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability). + +# Project security practices + +FHIR Package Loader uses NPM for dependency management. Dependencies with security vulnerabilities as reported by NPM's audit tool should be updated to secure versions as soon as possible. A new version of FHIR Package Loader that resolves the vulnerabilities should be released as soon as possible afterwards. Pull requests that include new dependencies should not include dependencies that contain known security vulnerabilities. + +As part of reviewing pull requests, code changes will be examined for potential security issues. Security issues discovered during pull request review must be resolved before the pull request will be accepted. From 0e5184fecec35d29abe2acfc31f54cd890b421e4 Mon Sep 17 00:00:00 2001 From: Julia Afeltra <30803904+jafeltra@users.noreply.github.com> Date: Fri, 14 Jun 2024 10:09:19 -0400 Subject: [PATCH 2/5] Add CONTRIBUTING.md and CODE-OF-CONDUCT.md (#25) --- CODE-OF-CONDUCT.md | 7 ++++ CONTRIBUTING.md | 99 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 106 insertions(+) create mode 100644 CODE-OF-CONDUCT.md create mode 100644 CONTRIBUTING.md diff --git a/CODE-OF-CONDUCT.md b/CODE-OF-CONDUCT.md new file mode 100644 index 0000000..dc7f021 --- /dev/null +++ b/CODE-OF-CONDUCT.md @@ -0,0 +1,7 @@ +# Contributor Code of Conduct + +The FHIR Shorthand team is committed to fostering a welcoming community. + +Our Code of Conduct can be found here: + +https://www.hl7.org/legal/code-of-conduct.cfm diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..0913071 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,99 @@ +# Contributing + +We're glad you're thinking about contributing to FHIR Package Loader! We welcome all friendly contributions, including: + +- bug reports +- comments and suggestions +- feature requests +- bug fixes +- feature implementations and enhancements +- documentation updates and additions + +To ensure a welcoming environment, we follow the [HL7 Code of Conduct](https://www.hl7.org/legal/code-of-conduct.cfm) and expect contributors to do the same. + +Before making a contribution, please familiarize yourself with this document, as well as our [LICENSE](LICENSE) and [README](README.md). + +## Issues + +We use GitHub issues to track bug reports, comments, suggestions, questions, and feature requests. + +Before submitting a new issue, please check to make sure a similar issue isn't already open. If one is, contribute to that issue thread with your feedback. + +When submitting a bug report, please try to provide as much detail as possible. This may include: + +- steps to reproduce the problem +- screenshots demonstrating the problem +- the full text of error messages +- relevant outputs +- any other information you deem relevant + +Please note that the GitHub issue tracker is _public_; any issues you submit are immediately visible to everyone. For this reason, do _not_ submit any information that may be considered sensitive. + +## Zulip + +In addition to GitHub issues, we also use the FHIR Community Chat @ https://chat.fhir.org to discuss the use of FHIR Shorthand and its associated projects. The [#shorthand stream](https://chat.fhir.org/#narrow/stream/215610-shorthand) is used for all FHIR Shorthand questions and discussion. + +Before contributing to the discussion on the #shorthand stream, you will need to register for an account. The instructions to sign up can be found when you visit https://chat.fhir.org. + +Before starting a new conversation, please check for earlier discussions on a similar issue or topic. If a previous conversation has been started, contribute to that thread with your feedback. + +When starting a new conversation, please use a descriptive topic and include as much detail as possible. + +## Code Contributions + +If you are planning to work on a reported bug, suggestion, or feature request, please comment on the relevant issue to indicate your intent to work on it. +If there is no associated issue, please submit a new issue describing the feature you plan to implement or the bug you plan to fix. +This reduces the likelihood of duplicated effort and also provides the maintainers an opportunity to ask questions, provide hints, or indicate any concerns _before_ you invest your time. + +### Coding Practices + +Code that is contributed to this project should be done in a personal fork of this repository and follow the coding practices specified in our Best Practices documentation (coming soon!). + +### Before Submitting a Pull Request + +Before submitting a Pull Request for a code contribution: + +- [Merge](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging) master into your branch or [rebase](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) on master if your code is out of sync with master + - If you need help with this, submit your Pull Request without merging or rebasing and indicate you need help +- Build the code (if applicable) and ensure there are no new warnings or errors +- Run the tests with `npm test` and ensure that all tests pass +- Run the linter with `npm run lint` and ensure that there are no linter warnings or errors +- Run the Prettier formatter with `npm run prettier` and ensure that there are no formatting warnings or errors + + _Note: `npm run check` will run the `test`, `lint`, and `prettier` scripts at once_ + +- Ensure any new dependencies do not contain known security vulnerabilities. + - We recommend using `npm audit` to ensure there are no new security vulnerabilities introduced on your branch + +For details on how to build, test, lint, and format see the individual project README file. + +### Submitting a Pull Request + +Pull requests should include a summary of the work, as well as any specific guidance regarding how to test or invoke the code. + +When project maintainers review the pull request, they will: + +- Verify the contribution is compatible with the project's goals and mission +- Run the project's unit tests, linters, and formatters to ensure there are no violations +- Deploy the code locally to ensure it works as expected +- Review all code changes in detail, looking for: + - potential bugs, regressions, security issues, or unintended consequences + - edge cases that may not be properly handled + - application of generally accepted best practices + - adequate unit tests and documentation + +### If the Pull Request Passes Review + +Congratulations! Your code will be merged by a maintainer into the project's master branch! + +### If the Pull Request Does Not Pass Review + +If the review process uncovers any issues or concerns, a maintainer will communicate them via a Pull Request comment. In most cases, the maintainer will also suggest changes that can be made to address those concerns and eventually have the Pull Request accepted. If this happens: + +- address any noted issues or concerns +- rebase or merge master (if necessary) and push your code again (may require a force push if you rebased) +- comment on the Pull Request indicating it is ready for another review + +## Apache 2.0 + +All contributions to this project will be released under the [Apache 2.0 license](http://www.apache.org/licenses/LICENSE-2.0). By submitting a pull request, you are agreeing to comply with this license. As indicated by the license, you are also attesting that you are the copyright owner, or an individual or Legal Entity authorized to submit the contribution on behalf of the copyright owner. From 3b2a62046ee83bdf0459b309301f0c4756f09658 Mon Sep 17 00:00:00 2001 From: Julia Afeltra <30803904+jafeltra@users.noreply.github.com> Date: Fri, 21 Jun 2024 13:51:34 -0400 Subject: [PATCH 3/5] Add Best Practices (#26) - Add Best Practices document - Add PR template - Update Contributing document with latest updates --- .github/pull_request_template.md | 5 +++ BEST-PRACTICES.md | 57 ++++++++++++++++++++++++++++++++ CONTRIBUTING.md | 8 +++-- 3 files changed, 68 insertions(+), 2 deletions(-) create mode 100644 .github/pull_request_template.md create mode 100644 BEST-PRACTICES.md diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md new file mode 100644 index 0000000..eb205d7 --- /dev/null +++ b/.github/pull_request_template.md @@ -0,0 +1,5 @@ +**Description:** + +**Testing Instructions:** + +**Related Issue:** diff --git a/BEST-PRACTICES.md b/BEST-PRACTICES.md new file mode 100644 index 0000000..e7fa2b2 --- /dev/null +++ b/BEST-PRACTICES.md @@ -0,0 +1,57 @@ +# Best Practices + +We're glad you're considering contributing to FHIR Package Loader (FPL)! Below are a few best practices that we recommend for all contributions. + +## Before Contributing + +Before contributing a feature or a bugfix, we recommend creating a GitHub issue if one does not exist. This allows the community to provide feedback on why an issue may be occurring or provide additional insight into a suggested feature. See the [Contribution Policy](CONTRIBUTING.md#issues) to learn more about creating issues. It may also be useful, but is not required, to start a Zulip conversation around the feature or bug. See the [Contribution Policy](CONTRIBUTING.md#zulip) to learn more about Zulip. + +If a GitHub issue already exists for what you are planning to contribute, we recommend commenting on the issue to indicate that you are working on an implementation to avoid duplication of work. + +## Coding Practices + +We recommend the following coding practices for high quality contributions: + +- Make all changes in a personal [fork](https://help.github.com/articles/fork-a-repo/) of this repository. +- Use descriptive commit messages. +- Prefer self-explanatory code as much as possible, but provide helpful comments for complex expressions and code blocks. +- Add unit tests for any new or changed functionality, and update any existing tests that are impacted by your changes. + - FPL uses [Jest](https://jestjs.io/) as a testing framework. + - To run the full test suite, run `npm test`. + - To review the test coverage report, run `npm run coverage` after running the full test suite. + - Ensure all tests are passing. Ensure that code coverage of the new code is complete. +- Follow the code style and conventions as enforced by the lint configuration and as evidenced by the existing code. + - FPL uses [ESLint](https://eslint.org/) for code linting. + - To run the linter on all code, run `npm run lint`. + - To automatically fix as many issues as possible, run `npm run lint:fix`. This uses ESLint's [--fix](https://eslint.org/docs/latest/use/command-line-interface#fix-problems) option. + - Ensure there are no issues reported. +- Follow the code formatting as enforced by the formatter configuration. + - FPL uses [Prettier](https://prettier.io/) for code formatting. + - To run Prettier on all code, run `npm run prettier`. + - To automatically rewrite files in order to resolve formatting issues, run `npm run prettier:fix`. This uses Prettier's [--write](https://prettier.io/docs/en/cli.html#--write) option. + - Ensure there are no issues reported. +- Ensure any new dependencies use the latest published version. + - If a new dependency is required but the latest published version cannot be used, add the dependency and reason for not updating to [DEPENDENCY-NOTES.md](DEPENDENCY-NOTES.md). + - To check the latest published version, check the versions of the package on [npm](https://www.npmjs.com/) or use [npm-outdated](https://docs.npmjs.com/cli/v10/commands/npm-outdated). Run `npm outdated` and check that the new dependency is not listed in the output. +- Ensure any new dependencies do not contain any known security vulnerabilities + - To check for known security vulnerabilities, we recommend using [npm-audit](https://docs.npmjs.com/cli/v10/commands/npm-audit). Run `npm audit` and ensure there are no new issues on your branch. +- Update documentation to reflect any user-facing changes. + - Documentation updates may include, but are not limited to, the project [README](README.md). + +## Making a Pull Request + +We recommend the following best practices for creating a high quality pull request: + +- Review your own PR before marking it as ready for review by others. Ensure the only code changes included are ones relevant to the feature or bugfix and that they follow the coding practices outlined above. +- Ensure your branch is up to date with master. There are a few ways you can update your branch: + - Use the "Update branch" button available once you make your PR. This is the recommended approach if you are not comfortable with merging or rebasing. + - [Merge](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging) master into your branch. + - [Rebase](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) your branch on master. We only recommend this approach if you are very comfortable with rebasing. +- Update the title of the PR to provide a short, descriptive summary of the PR. + - Keep the title up to date with any changes made during the review process. The title will be used in the commit message and in the release notes, so it is important that it accurately reflects the current state of the PR. +- Follow the pull request template to create a detailed PR description. + - Include a detailed description of the changes made in the PR. + - Include instructions for how to test the PR. You may want to include a link to sample FSH in FSH Online to demonstrate a bug or attach a sample project that highlights new or improved behavior. + - [Link the issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) that the PR addresses. +- Follow up on any discussion on your PR. If changes are requested, make any necessary updates and comment indicating your PR is ready for re-review. +- If your PR is approved, it will be merged to master using the "[squash and merge](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-commits)" strategy. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0913071..b980756 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -15,7 +15,7 @@ Before making a contribution, please familiarize yourself with this document, as ## Issues -We use GitHub issues to track bug reports, comments, suggestions, questions, and feature requests. +We use GitHub issues to track bug reports, comments, suggestions, questions, and feature requests. If you need help with using FHIR Shorthand or its tools, however, you may want to consider posting on Zulip first (see below). Questions posted on Zulip will reach a broader set of FSH users and will likely receive more timely responses. Requests for specific changes, however, should be submitted as GitHub issues so they can be formally tracked. Before submitting a new issue, please check to make sure a similar issue isn't already open. If one is, contribute to that issue thread with your feedback. @@ -27,6 +27,8 @@ When submitting a bug report, please try to provide as much detail as possible. - relevant outputs - any other information you deem relevant +When creating or contributing to an issue, please include a link to any relevant discussion threads on Zulip (see below). + Please note that the GitHub issue tracker is _public_; any issues you submit are immediately visible to everyone. For this reason, do _not_ submit any information that may be considered sensitive. ## Zulip @@ -39,6 +41,8 @@ Before starting a new conversation, please check for earlier discussions on a si When starting a new conversation, please use a descriptive topic and include as much detail as possible. +If you are looking for feedback or discussion around an issue, we recommend using Zulip. The FSH community is active on Zulip, and it is the best place to have in-depth discussions and ask questions about the FSH tooling. If the discussion on Zulip determines that a change is required in FHIR Package Loader, you should create a GitHub issue to track it. The GitHub issue should include a link to the relevant Zulip discussion thread, and it is best practice to provide a link to the GitHub issue on the Zulip thread. While Zulip is very useful for discussion, GitHub issues are the system of record for changes to FHIR Package Loader. + ## Code Contributions If you are planning to work on a reported bug, suggestion, or feature request, please comment on the relevant issue to indicate your intent to work on it. @@ -47,7 +51,7 @@ This reduces the likelihood of duplicated effort and also provides the maintaine ### Coding Practices -Code that is contributed to this project should be done in a personal fork of this repository and follow the coding practices specified in our Best Practices documentation (coming soon!). +Code that is contributed to this project should be done in a personal fork of this repository and follow the coding practices specified in our Best Practices documentation in [BEST-PRACTICES.md](BEST-PRACTICES.md). ### Before Submitting a Pull Request From e27120c847ba95d026bd21e54c89656d59f890f4 Mon Sep 17 00:00:00 2001 From: Mint Thompson Date: Fri, 19 Jul 2024 15:42:09 -0400 Subject: [PATCH 4/5] Add FHIR Foundation project statement to readme (#31) * Add FHIR Foundation project statement to readme * Update README.md --- README.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/README.md b/README.md index 43d2994..96ad657 100644 --- a/README.md +++ b/README.md @@ -2,6 +2,15 @@ FHIR Package Loader is a utility that downloads published FHIR packages from the FHIR package registry. +## FHIR Foundation Project Statement + +- Maintainers: This project is maintained by The MITRE Corporation. +- Issues / Discussion: For FHIR Package Loader issues, such as bug reports, comments, suggestions, questions, and feature requests, visit [FHIR Package Loader GitHub Issues](https://github.com/standardhealth/fhir-package-loader/issues). For discussion of FHIR Shorthand and its associated projects, visit the FHIR Community Chat @ https://chat.fhir.org. The [#shorthand stream](https://chat.fhir.org/#narrow/stream/215610-shorthand) is used for all FHIR Shorthand questions and discussion. +- License: All contributions to this project will be released under the Apache 2.0 License, and a copy of this license can be found in [LICENSE](LICENSE). +- Contribution Policy: The FHIR Package Loader Contribution Policy can be found in [CONTRIBUTING.md](CONTRIBUTING.md). +- Security Information: The FHIR Package Loader Security Information can be found in [SECURITY.md](SECURITY.md). +- Compliance Information: FHIR Package Loader is designed to work with FHIR packages that are based on FHIR R4, FHIR R4B, or FHIR R5. + # Usage This tool can be used directly through a command line interface (CLI) or it can be used as a dependency in another JavaScript/TypeScript project to download FHIR packages and load the contents into memory. From a3888f87bf33815e3fad40b59620a87eb471c370 Mon Sep 17 00:00:00 2001 From: Mint Thompson Date: Thu, 12 Sep 2024 09:23:45 -0400 Subject: [PATCH 5/5] Update copyright and maintainers in README (#37) --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 96ad657..806df17 100644 --- a/README.md +++ b/README.md @@ -4,7 +4,7 @@ FHIR Package Loader is a utility that downloads published FHIR packages from the ## FHIR Foundation Project Statement -- Maintainers: This project is maintained by The MITRE Corporation. +- Maintainers: This project is maintained by the HL7 community. - Issues / Discussion: For FHIR Package Loader issues, such as bug reports, comments, suggestions, questions, and feature requests, visit [FHIR Package Loader GitHub Issues](https://github.com/standardhealth/fhir-package-loader/issues). For discussion of FHIR Shorthand and its associated projects, visit the FHIR Community Chat @ https://chat.fhir.org. The [#shorthand stream](https://chat.fhir.org/#narrow/stream/215610-shorthand) is used for all FHIR Shorthand questions and discussion. - License: All contributions to this project will be released under the Apache 2.0 License, and a copy of this license can be found in [LICENSE](LICENSE). - Contribution Policy: The FHIR Package Loader Contribution Policy can be found in [CONTRIBUTING.md](CONTRIBUTING.md). @@ -206,7 +206,7 @@ While the CLI and API should be sufficient for the majority of use cases, FHIR P # License -Copyright 2022 The MITRE Corporation +Copyright 2022-2024 Health Level Seven International Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.