{"id":15012157,"url":"https://github.com/microsoft/powerstig","last_synced_at":"2025-05-15T07:04:55.496Z","repository":{"id":39176540,"uuid":"132100529","full_name":"microsoft/PowerStig","owner":"microsoft","description":"STIG Automation ","archived":false,"fork":false,"pushed_at":"2025-05-06T08:29:15.000Z","size":25272,"stargazers_count":572,"open_issues_count":73,"forks_count":119,"subscribers_count":47,"default_branch":"dev","last_synced_at":"2025-05-15T00:08:35.470Z","etag":null,"topics":["powershell","stig","stig-compliant"],"latest_commit_sha":null,"homepage":"https://www.powershellgallery.com/packages/PowerSTIG","language":"PowerShell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/microsoft.png","metadata":{"files":{"readme":"README.CONTRIBUTING.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2018-05-04T06:52:53.000Z","updated_at":"2025-05-11T11:16:12.000Z","dependencies_parsed_at":"2023-02-06T08:00:37.736Z","dependency_job_id":"0cbaa362-d50c-4e78-8fd2-3d85551221fd","html_url":"https://github.com/microsoft/PowerStig","commit_stats":{"total_commits":1402,"total_committers":37,"mean_commits":"37.891891891891895","dds":0.8323823109843081,"last_synced_commit":"6557a225a237eaa5e21062b31a567ceff637c72d"},"previous_names":[],"tags_count":47,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/microsoft%2FPowerStig","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/microsoft%2FPowerStig/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/microsoft%2FPowerStig/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/microsoft%2FPowerStig/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/microsoft","download_url":"https://codeload.github.com/microsoft/PowerStig/tar.gz/refs/heads/dev","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254292039,"owners_count":22046426,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["powershell","stig","stig-compliant"],"created_at":"2024-09-24T19:42:11.047Z","updated_at":"2025-05-15T07:04:50.474Z","avatar_url":"https://github.com/microsoft.png","language":"PowerShell","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Contributing to PowerStig\n\nWelcome to PowerStig!\nWe're thrilled that you'd like to contribute!\n\nThere are a few different ways you can contribute:\n\n* [Submit an issue](#submitting-an-issue)\n* [Fix an issue](#fixing-an-issue)\n* [Write documentation](#writing-documentation)\n* [Review pull requests](#reviewing-pull-requests)\n\nIf you're new to GitHub, begin by reading the excellent [guide to getting started with GitHub](https://github.com/PowerShell/DscResources/blob/master/GettingStartedWithGitHub.md) over on the DscResources repository.\n\nIf you have any questions or concerns, feel free to reach out to [@athaynes](https://github.com/athaynes), [@jcwalker](https://github.com/jcwalker), or [@regedit32](https://github.com/regedit32) for help.\n\nThis project welcomes contributions and suggestions.  Most contributions require you to agree to a\nContributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us\nthe rights to use your contribution. For details, visit https://cla.microsoft.com.\n\nWhen you submit a pull request, a CLA-bot will automatically determine whether you need to provide\na CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions\nprovided by the bot. You will only need to do this once across all repositories using our CLA.\n\nThis project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).\nFor more information, see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or\ncontact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments.\n\n## Submitting an Issue\n\nSubmitting an issue to PowerStig is easy!\n\nHere are the steps:\n\n1. Make sure the issue is not open already.\n1. Open a new issue.\n1. Fill in the issue title.\n1. Fill in the issue description.\n1. Submit the issue.\n\n### Open an Issue\n\nOnce you are in the correct repository to submit your issue, go to the Issues tab.\n![GitHubIssuesTab](https://github.com/PowerShell/DscResources/blob/master/Images/GitHubIssuesTab.png)\n\n**Ensure that the issue you are about to file is not already open.**\nIf someone has already opened a similar issue, please leave a comment or add a GitHub reaction to the top comment to **express your interest**. You can also offer help and use the issue to coordinate your efforts in fixing the issue.\n\nIf you cannot find an issue that matches the one you are about to file, click the New Issue button on the right.\n![GitHubNewIssueButton](https://github.com/PowerShell/DscResources/blob/master/Images/GitHubNewIssueButton.png)\n\nA new, blank issue should open up.\n![GitHubBlankIssue](https://github.com/PowerShell/DscResources/blob/master/Images/GitHubBlankIssue.PNG)\n\n### Fill in Issue Title\n\nThe issue title should be a summary of your issue in one sentence.\n\nIf you would like to submit an issue that would include a breaking change, please refer to our [Breaking Changes](#breaking-changes) section below.\n\n### Fill in Issue Description\n\nThe issue description should contain a **detailed** report of the issue you are submitting.\nIf you are submitting a bug, please include any error messages or stack traces caused by the problem.\n\nPlease reference any related issues or pull requests by a pound sign followed by the issue or pull request number (e.g., #11, #72). GitHub will automatically link the number to the corresponding issue or pull request. You can also link to pull requests and issues in other repositories by including the repository owner and name before the issue number.\nLike this:\n\n```cmd\n\u003cowner name\u003e/\u003crepository name\u003e#\u003cnumber of PR/issue\u003e\n```\n\nSo to link to issue #23 in the PowerStigDsc repository, which Microsoft owns:\n\n```cmd\nMicrosoft/PowerStigDsc#23\n```\n\nPlease also tag any GitHub users you would like to notice this issue. You can tag someone on GitHub with the @ symbol followed by their username (e.g., @athaynes).\n\n### Submit an Issue\n\nOnce you have filled out the issue title and description, click the submit button at the bottom of the issue.\n![GitHubIssueSubmitButton](https://github.com/PowerShell/DscResources/blob/master/Images/GitHubIssueSubmitButton.png)\n\n## Fixing an Issue\n\nHere's the general process of fixing an issue in PowerStig:\n\n1. Pick out the issue you'd like to work on.\n1. Create a fork of the repository that contains the issue.\n1. Clone your fork to your machine.\n1. Create a working branch where you can store your updates to the code.\n1. Make changes in your working branch to solve the issue.\n1. Write tests to ensure that the issue is fixed.\n1. Update the 'Unreleased' section of the module's release notes to include your changes.\n1. Submit a pull request to the dev branch of the official repository for review.\n1. Make sure all tests are passing in AppVeyor for your pull request.\n1. Make sure your code does not contain merge conflicts.\n1. Address any comments brought up by the reviewer.\n\n### Pick an Issue\n\nIssues that are currently up-for-grabs have the `help wanted` label.\n\nIf you find an issue that you want to work on, but does not have the `help wanted` label, make sure to read through the issue and ask if you can start working on it.\n\n### Fork a Repository\n\nA 'fork' on GitHub is your copy of a repository.\nGitHub's guide to forking a repository is available [here](https://help.github.com/articles/fork-a-repo/).\nYou will need a fork to contribute to any of the repositories in PowerStig since only the maintainers can push to the official repositories.\n\nOnce you have created your fork, you can easily access it via the URL:\n\n```cmd\nhttps://github.com/\u003cyour GitHub username\u003e/\u003cmodule name\u003e\n```\n\n### Clone your Fork\n\nYou will want to clone your fork so that you can edit code locally on your machine.\nGitHub's guide to cloning is available [here](https://help.github.com/articles/cloning-a-repository/).\n\n### Create a Working Branch\n\nWe use a [git flow](http://nvie.com/posts/a-successful-git-branching-model/) model in our official repositories.\n\nYour fork is your territory.\nYou may set it up to best suit your workflow, but we recommend creating a working branch separate from the default `dev` branch.\nThe working branch separate from the default dev branch will allow you to create other working branches off of dev later while your original working branch is still open for code reviews.\nLimiting your current working branch to a single issue will also streamline the code review and reduce the possibility of merge conflicts.\n\nThe Git guide to branching is available [here](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging).\n\n### Make Code Changes\n\nWhen writing code for any of the modules in PowerStig, please follow PowerStig [Style Guidelines](https://github.com/PowerShell/DscResources/blob/master/StyleGuidelines.md) and [Best Practices](https://github.com/PowerShell/DscResources/blob/master/BestPractices.md).\nThese guidelines are from the PowerShell/DscResources projects and may not always reflect the same PowerShell style as other projects.\nCode reviewers will expect you to follow these guidelines and may ask you to change your code for consistency.\n\nIf you need help committing and pushing your code to your fork, please refer to our [guide to getting started with GitHub](https://github.com/PowerShell/DscResources/blob/master/GettingStartedWithGitHub.md).\n\nPay attention to any new code merged into the dev branch of the official repository. If this occurs, you will need to pick-up these changes in your fork using the rebase instructions in our [guide to getting started with GitHub](https://github.com/PowerShell/DscResources/blob/master/GettingStartedWithGitHub.md).\n\nIf you are making a breaking change, please read the [Breaking Changes section](#breaking-changes) below.\n\n### Write Tests\n\nAll modules in PowerStig should have tests written using [Pester](https://github.com/pester/Pester) in the [Tests folder](Tests/).\nYou are required to provide adequate test coverage for the code you change.\n\nPlease refer to our [testing guidelines](README.TESTGUIDELINES.md) for information on writing tests for PowerStig.\nOur test templates and guidelines are currently under construction.\nUse them with caution as they are subject to change soon.\n\nTests should currently be structured like so:\n\n* Root folder of module\n  * Tests\n    * Unit\n      * Module.Tests.ps1\n    * Integration\n      * Module.Integration.Tests.ps1\n\nNot all modules currently have tests.\nHowever, this does not mean that you do not have to write tests for your changes.\nIf you find that the test file for a module is missing or one of the folders in the structure outlined above is missing, please create it.\nYou don't have to write the full set of tests for the module if you create the file.\nYou only need to test the changes that you made to the module.\n\n### Update the Release Notes\n\nRelease notes for each module are included in the [README.md](README.md) under the root folder.\nCurrently, unreleased changes are listed under the 'Unreleased' section under the 'Versions' header.\nIf this section is missing, please add it.\n\nTo update the release notes with your changes, simply add a bullet point (or more) with your changes in the **past** tense under the 'Unreleased' section.\nFor example:\n\n```cmd\n...\n## Versions\n\n### Unreleased\n- Added the FriendlyName parameter to ConvertTo-PowerStigXml\n\n### 1.0.0.0\n...\n```\n\nIf you are making a breaking change, please read the [Breaking Changes section](#breaking-changes) below.\n\n### Submit a Pull Request\n\nA [pull request](https://help.github.com/articles/using-pull-requests/) (PR) allows you to submit the changes you made in your fork to the official repository.\n\nGo to the Pull Requests tab of either your fork or the official repository to open a pull request.\n![GitHubPullRequestsTabInFork.png](https://github.com/PowerShell/DscResources/blob/master/Images/GitHubPullRequestsTabInFork.png)\n\nClick the New Pull Request button on the right:\n![GitHubNewPullRequestButton.png](https://github.com/PowerShell/DscResources/blob/master/Images/GitHubNewPullRequestButton.png)\n\nThe base is the repository and branch that the pull request will be merging **into**.\nThe target is your fork of the repository and the branch the pull request will be merging **from**.\nFor PowerStig, always create a pull request with the base as the **dev** branch of the official repository.\nThe target should be your working branch in your fork.\n![Github-PR-dev.png](https://github.com/PowerShell/DscResources/blob/master/Images/Github-PR-dev.png)\n\nOnce you select the correct base and target, you can review the files and commits the pull request will include by selecting the tabs below the Create Pull Requests Button:\n![GitHubPullRequestFileReview.png](https://github.com/PowerShell/DscResources/blob/master/Images/GitHubPullRequestFileReview.png)\n\nIf GitHub asserts that it cannot automatically merge your branch, you presumably have merge conflicts. Fix all outstanding merge conflicts before you submit your pull request.\n![GitHubPullRequestPreCreateMergeConflict.png](https://github.com/PowerShell/DscResources/blob/master/Images/GitHubPullRequestPreCreateMergeConflict.png)\n\nFor help fixing merge conflicts, see our [guide to getting started with GitHub](https://github.com/PowerShell/DscResources/blob/master/GettingStartedWithGitHub.md).\n\nOnce you are ready to submit your pull request, click the Create Pull Request button.\n![GitHubCreatePullRequestButton.png](https://github.com/PowerShell/DscResources/blob/master/Images/GitHubCreatePullRequestButton.png)\n\n#### Pull Request Title\n\nThe title of your PR should *describe* the changes it includes in one line.\nMerely putting the issue number that the PR fixes is not acceptable.\nIf your PR deals with *one* specific module, please prefix the title with the module name followed by a colon.\nIf your PR fixes an issue, please include \"(Fixes #issue number)\" in the title.\nFor example, if the PR fixes issue number 11 and 16, which adds the Ensure parameter, the title should be something like:\n\"Module: Added Ensure parameter (Fixes #11, #16)\".\n\nPlease refer to the [Breaking Changes](#breaking-changes) section below if your pull request includes a breaking change.\n\nIf you open a pull request with the wrong title, you can easily edit it by clicking the Edit button to the title's right in the open pull request.\n\n#### Pull Request Description\n\nThe description of your PR should include a detailed report of all the changes you made.\nIf your PR fixes an issue, please include the number in the description.\nPlease tag anyone you would specifically like to see this PR with the @ symbol followed by their GitHub username (e.g., @athaynes).\n\nOnce you are satisfied with the title, description, and file changes included, submit the pull request.\n\n#### Contribution License Agreement (CLA)\n\nIf this is your first contribution to PowerStig, you may need to sign a [Contribution Licensing Agreement](https://cla.microsoft.com/) (CLA) before your changes can be reviewed:\n![GitHubCLARequired.png](https://github.com/PowerShell/DscResources/blob/master/Images/GitHubCLARequired.png)\n\nOnce you sign the CLA, the Microsoft CLA bot will automatically update the comment in your PR:\n![GitHubCLASigned.png](https://github.com/PowerShell/DscResources/blob/master/Images/GitHubCLASigned.png)\n\nThe CLA status check should also pass in your PR.\n![GitHubCLAStatusCheck.png](https://github.com/PowerShell/DscResources/blob/master/Images/GitHubCLAStatusCheck.png)\n\nOnce you have signed our CLA, you shouldn't have to do it again.\nIf you believe you have signed our CLA before, but the Microsoft CLA bot still\nmarks your PR as \"CLA not signed yet\", or the CLA status check does not pass,\nplease sign the CLA again. Sometimes the little bot makes mistakes.\n\n### Tests in AppVeyor\n\nPowerStig uses [AppVeyor](http://www.appveyor.com/) as a continuous integration (CI) system.\n\nAfter submitting your pull request, AppVeyor will automatically run a suite of tests on your proposed changes.\nAfterward, AppVeyor will update the status of the pull request, providing at-a-glance feedback about whether your changes are passing tests or not.\n![AppVeyor-Github](https://github.com/PowerShell/DscResources/blob/master/Images/AppVeyor-Github.png)\n\nAll the green checkboxes and red crosses are **clickable**.\nThey will bring you to the corresponding test page with details on which tests are running and why your tests may be failing.\n\nA maintainer **will not** merge your pull request if these tests fail, even if they have nothing to do with your changes.\nIf test failures occur that do not relate to the changes you made, you will have to submit another PR with fixes for those failures or wait until someone else does.\n\nAny commit to the working branch that targets the pull request will trigger the tests to run again in AppVeyor.\nIf you tag a maintainer, they can also re-run your tests in AppVeyor.\n\nThe appveyor.yml file in each module repository describes the build and test sequence provided to AppVeyor.\n\nAn AppVeyor badge reflects the latest build status of the **master** and **dev** branches at the top of the README.md file of every module repository.\n![AppVeyor-Badge-Green.png](https://github.com/PowerShell/DscResources/blob/master/Images/AppVeyor-Badge-Green.png)\n\nThis badge is also **clickable**.\nIt opens the corresponding module's AppVeyor page, which shows test logs and results.\nFrom this page, you can easily navigate through the build history of the module.\n\n#### Common Tests\n\nThere is a set of common tests for all modules located in the [DSCResource.Tests](https://github.com/PowerShell/DscResource.Tests) repository.\n\nThese tests primarily concentrate on code style, file encoding, correct module schema, and PS Script Analyzer issues.\nThese tests are too good not to use and too complex to duplicate and maintain separately, even if they are geared toward DSC resources.\nPowerShell is PowerShell, so only a few of the tests do not apply to PowerStig.\n\nIt would be best if you run these tests before submitting a pull request.\nThe common DSC Resources tests are automatically downloaded into the root module folder when invoking tests.\nIf this is not happening for your module, you will need to clone [DSCResource.Tests](https://github.com/PowerShell/DscResource.Tests) into the root folder of the module that you want to test.\nThen simply run `Invoke-Pester` from the root folder.\n\nLike this:\n\n```cmd\ncd C:\\MyPath\\ResourceModuleFolder\ngit clone https://github.com/PowerShell/DscResource.Tests\nInvoke-Pester\n```\n\nPlease avoid adding the **DSCResource.Tests** folder to your changes.\nDSCResource.Tests should be in the .gitignore file so that Git will automatically ignore this folder.\nIf DSCResource.Tests is not in the .gitignore file; please add it.\nIf there is no .gitignore file for your module, instructions on adding one are available in our [getting started with GitHub](https://github.com/PowerShell/DscResources/blob/master/GettingStartedWithGitHub.md) instructions.\n\nThe [MetaFixers](https://github.com/PowerShell/DscResource.Tests/blob/master/MetaFixers.psm1) module also in [DSCResource.Tests](https://github.com/PowerShell/DscResource.Tests) contains a few fix-helper methods (e.g., converting all tab indentations to 4 spaces, correcting file encoding).\n\n### Fix Merge Conflicts\n\nIf you have merge conflicts, please use Git rebasing to fix them instead of Git merging.\nAn introduction to Git rebasing is available in the [getting started with GitHub](https://github.com/PowerShell/DscResources/blob/master/GettingStartedWithGitHub.md) instructions.\n\n### Get your Code Reviewed\n\nAnyone other than you can *review* your code, but only maintainers can *merge* your code.\nIf you have a specific contributor/maintainer you want to review your code, be sure to tag them in your pull request.\n\nWe don't currently have dedicated maintainers for most modules, so it may take a while for a general maintainer to get around to your pull request.\nPlease be patient.\n\n## Breaking Changes\n\nBreaking changes should first be proposed by opening an issue on the resource and outlining the needed work.\nAn issue allows the community to discuss the change before the work is done and scopes the breaks to needed areas.\n\nOpening an issue also allows the resource owner or PowerStig Owner ([@athaynes](https://github.com/athaynes)) to tag the issue with the `breaking change` label.\n\nBreaking changes may include:\n\n* Adding a new mandatory parameter\n* Changing an existing parameter\n* Removing an existing parameter\n* Fundamentally changing an existing functionality of a resource\n\nOnce a PR is ready with the breaking change, please include the following:\n\n1. At least one of the bullet points in your addition to the updated release notes starts with 'BREAKING CHANGE:'\n1. The title of the PR that includes your breaking change starts with 'BREAKING CHANGE:'\n\n## Writing Documentation\n\nOne of the easiest ways to contribute to a PowerShell project is to write and edit documentation.\nAll documentation in PowerStig uses [GitHub Flavored Markdown](https://guides.github.com/features/mastering-markdown/) (GFM).\nSee the [section below](#github-flavored-markdown) for more details.\n\nIf you want to contribute new documentation, first check for existing issues to ensure you're not duplicating efforts.\nIf no one seems to be working on what you have planned:\n\n1. Open a new issue to tell others about the documentation change/addition you'd like to make.\n1. Create a fork of the repository you would like the documentation to be added to.\n1. Edit or add the Markdown file (.md) you would like changed/added. To edit an existing file in the GitHub editor, simply navigate to it in GitHub and click the Edit button.\n1. When you're ready to contribute your documentation, [submit a pull request](#submit-a-pull-request) to the official repository.\n\n### GitHub Flavored Markdown\n\nIf you are looking for a good editor, try:\n\n* The web interface GitHub provides for .md files\n* [Markdown Pad](http://markdownpad.com/)\n* [VS Code](https://code.visualstudio.com/) with the [MarkdownLint](https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint) extension\n\nAn excellent guide to Github Flavored Markdown is available [here](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet).\n\n## Reviewing Pull Requests\n\nThough only maintainers can *merge* a pull request, anyone from the community can *review* a pull request.\nMaintainers will still take a quick look at code before merging it, but reviews by community members often help pull requests get merged much faster as there are very few maintainers and a lot of pull requests to review.\n\n**Pull requests should not be reviewed while tests from AppVeyor are failing.**\nIf you are confused about why tests in AppVeyor are failing, tag a maintainer or ask the community for help.\n\nAll modules in PowerStig should link to [Reviewable](https://reviewable.io), a code review tool.\nReviewable adds a purple button to the top comment of every pull request.\n![GitHubReviewableButton](https://github.com/PowerShell/DscResources/blob/master/Images/GitHubReviewableButton.png)\nThis button is **clickable**.\nIt will take you to a code review of all the changes in that pull request.\n\nIf the purple Reviewable button does not appear, you can also go [here](https://reviewable.io/reviews) and paste the URL of the pull request you would like to review into this box towards the bottom of the page:\n![ReviewablePullRequestPasteBox](https://github.com/PowerShell/DscResources/blob/master/Images/ReviewablePullRequestPasteBox.png)\n\nIf a pull request contains several changed files, Reviewable may collapse them and show you only one file at a time. If this happens, you can navigate to other files in the pull request by clicking the purple reviewable icon at the top of the page:\n![ReviewableFilePicker](https://github.com/PowerShell/DscResources/blob/master/Images/ReviewableFilePicker.png)\n\n### Making Review Comments\n\nYou can comment Reviewable in the top discussion section (for general/overall comments), or you can click on a line of code to comment on that line.\nEach comment you make will be saved as a draft so that you can continue making comments until you are ready to publish all of them at once. Publishing is discussed in the [Publish Review Changes](#publish-review-changes) section below.\nIf you want to delete a comment draft at a line of code, click the tiny trash icon at the bottom of the comment.\n\nSome things to pay attention to while reviewing:\n\n* Does the code logic make sense?\n* Does the code structure make sense?\n* Does this make the resource better?\n* Is the code easy to read?\n* Do all variables, parameters, and functions have **descriptive** names? (e.g. no $params, $args, $i, $a, etc.)\n* Does every function have a help comment?\n* Does the code follow PowerStig [Style Guidelines](https://github.com/PowerShell/DscResources/blob/master/StyleGuidelines.md) and [Best Practices](https://github.com/PowerShell/DscResources/blob/master/BestPractices.md)?\n* Has the author included test coverage for their changes?\n* Has the author updated the Unreleased section of the README with their changes?\n\n### Resolving Review Discussions\n\nWhen the author replies or makes the changes you requested and you are **satisfied** with the changes/reply, you will need to resolve the discussion. You can do this in one of two ways:\n\n1. Click the Acknowledge button on the comment ![ReviewableAcknowledgeButton](https://github.com/PowerShell/DscResources/blob/master/Images/ReviewableAcknowledgeButton.png)\n\n1. Click the small circle in the bottom right of the comment and select 'Satisfied'. ![ReviewableDiscussionStatusCircle](https://github.com/PowerShell/DscResources/blob/master/Images/ReviewableDiscussionStatusCircle.png)\n ![ReviewableDiscussionSatisfied](https://github.com/PowerShell/DscResources/blob/master/Images/ReviewableDiscussionSatisfied.png)\n\n### Marking Files as Reviewed\n\nTo mark an entire file as reviewed, click the little eye button next to the file name at the top of the file so that it turns green.\n![ReviewableFileReviewButtonRed](https://github.com/PowerShell/DscResources/blob/master/Images/ReviewableFileReviewButtonRed.png)\n![ReviewableFileReviewButtonGreen](https://github.com/PowerShell/DscResources/blob/master/Images/ReviewableFileReviewButtonGreen.png)\n\n### Approving a Pull Request\n\nPlease mark all files and discussions as resolved before you approve the entire pull request.\n\nTo approve the pull request, you can click the LGTM (looks good to me) button in the main discussion at the top of the code review in Reviewable:\n![ReviewableLGTMButton](https://github.com/PowerShell/DscResources/blob/master/Images/ReviewableLGTMButton.png)\nOr you can simply comment on the pull request on GitHub \"Looks good to me\" or a thumbs up.\n\n### Publishing Review Changes\n\nTo push your comments and files marked as reviewed to the pull request on GitHub, you will need to publish your changes.\nThis can be done two different ways:\n\n1. (RECOMMENDED) Click the large green Publish button at the top of the page:\n  ![ReviewablePublishButton](https://github.com/PowerShell/DscResources/blob/master/Images/ReviewablePublishButton.png)\n  This will publish all your changes at once and submit them as one comment to the pull request on GitHub.\n1. (NOT RECOMMENDED) Click the small publish button on a comment.\n  This will publish only that one comment as a separate comment on Github.\n  Please do not publish this way as it will often send a separate email for each comment to whoever is watching the pull request on GitHub.\n  This method also will **not** publish the files you have marked as reviewed with the little eye button.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmicrosoft%2Fpowerstig","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmicrosoft%2Fpowerstig","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmicrosoft%2Fpowerstig/lists"}