Clean up Markdown Rule Violations and change Chat Icons - Fixes #512 (#521)

* Clean up Markdown * Change Gitter Icon to Slack * Add Discord Icon * Changes as per PR comments

Author: PlagueHO

.markdownlint.json

@@ -0,0 +1,10 @@
+{
+ "default": true,
+ "MD029": {
+ "style": "one"
+ },
+ "MD013": true,
+ "MD024": false,
+ "MD034": false,
+ "no-hard-tabs": true
+}

Automation.md

@@ -4,6 +4,11 @@ Some areas and workflows of the DSC Resource Kit are automated, and future
 automation will cover other areas. This document has both information around
 present automations, and potential future automations.
 
+> Important note: the Waffle Board is being deprecated in favor of using a
+> [GitHub Project board](https://github.com/orgs/PowerShell/projects/1).
+> The documentation in this document is yet to be updated to reflect this
+> new board.
+
 ## Table of Contents
 
 - [Labels](#labels)

CONTRIBUTING.md

@@ -8,10 +8,13 @@
 
 - 08/07/19
 
-All changes for the release should be merged into the `dev` branch before the release date. 
-Resource modules that are not passing their tests in the release pull request from the `dev` branch to the `master` branch cannot be released. 
-Resource modules with open issues labeled `blocking release` cannot be released. 
-Individual resource module hotfixes for urgent issues may be released before the official release date on a case-by-case basis. 
+All changes for the release should be merged into the `dev` branch before the
+release date.
+Resource modules that are not passing their tests in the release pull request
+from the `dev` branch to the `master` branch cannot be released.
+Resource modules with open issues labeled `blocking release` cannot be released.
+Individual resource module hotfixes for urgent issues may be released before the
+official release date on a case-by-case basis.
 
 ### Latest Release
 
@@ -72,7 +75,8 @@ Individual resource module hotfixes for urgent issues may be released before the
 - [05/08/19 12PM-1PM PST](https://github.com/PowerShell/DscResources/blob/master/CommunityCalls/2019-05-08)
 - [03/27/19 12PM-1PM PST](https://github.com/PowerShell/DscResources/blob/master/CommunityCalls/2019-03-27)
 - [02/13/19 12PM-1PM PST](https://github.com/PowerShell/DscResources/blob/master/CommunityCalls/2019-02-13)
-- [01/09/19 12PM-1PM PST](https://github.com/PowerShell/DscResources/blob/master/CommunityCalls/2019-01-09) - [watch here](https://youtu.be/hH2XkR-YZNQ)
+- [01/09/19 12PM-1PM PST](https://github.com/PowerShell/DscResources/blob/master/CommunityCalls/2019-01-09)
+ -- [watch here](https://youtu.be/hH2XkR-YZNQ)
 - 11/28/18 12-1PM PST - cancelled due to technical issues
 - [10/10/18 12-1PM PST](https://github.com/PowerShell/DscResources/blob/master/CommunityCalls/2018-10-10)
 - [08/29/18 12-1PM PST](https://github.com/PowerShell/DscResources/blob/master/CommunityCalls/2018-08-29)

CommunityAgenda.md

@@ -137,10 +137,10 @@ to send changes there.
 
 ```plaintext
 > git remote -v
-myhttps://github.com/vors/xActiveDirectory (fetch)
-myhttps://github.com/vors/xActiveDirectory (push)
-originhttps://github.com/PowerShell/xActiveDirectory (fetch)
-originhttps://github.com/PowerShell/xActiveDirectory (push)
+my https://github.com/vors/xActiveDirectory (fetch)
+my https://github.com/vors/xActiveDirectory (push)
+origin https://github.com/PowerShell/xActiveDirectory (fetch)
+origin https://github.com/PowerShell/xActiveDirectory (push)
 ```
 
 Now you have two remote references:
@@ -497,4 +497,5 @@ In a PowerShell prompt, you need to do the following.
  git push my changes-from-PR#<number> --force # Change to the PR number, i.e. git push my changes-from-PR#34 --force
  ```
 
-1. Now, go to you forked repository on GitHub and create the pull request the normal way.
+1. Now, go to you forked repository on GitHub and create the pull request the
+ normal way.

GettingStartedWithGitHub.md

@@ -1,12 +1,14 @@
 # DSC Resource Kit Maintainers
 
-Maintainers are trusted contributors with knowledge in a resource module domain who have [write access](https://help.github.com/articles/permission-levels-for-an-organization-repository/) to one or more DSC Resource Kit repositories.
+Maintainers are trusted contributors with knowledge in a resource module domain
+who have [write access](https://help.github.com/articles/permission-levels-for-an-organization-repository/)
+to one or more DSC Resource Kit repositories.
 
 Maintainers have the power to:
 
 1. `push`.
-2. Merge pull requests.
-3. Assign labels, milestones and people to [issues](https://guides.github.com/features/issues/).
+1. Merge pull requests.
+1. Assign labels, milestones and people to [issues](https://guides.github.com/features/issues/).
 
 ## Table of Contents
 
@@ -112,23 +114,33 @@ and Mariah Breakey ([@mbreakey3](https://github.com/mbreakey3)).
 If you are maintainer, please follow these rules:
 
 1. **DO** take care of pull requests in a timely manner.
-1. **DO** ensure that each contributor has signed a valid Contributor License Agreement (CLA).
-1. **DO** reply to new issues and pull requests (after you finish reviewing and everything looks good to you, leave a comment like "Looks good to me" or "LGTM" so we know that someone has looked at it and approved it).
+1. **DO** ensure that each contributor has signed a valid Contributor License
+ Agreement (CLA).
+1. **DO** reply to new issues and pull requests (after you finish reviewing and
+ everything looks good to you, leave a comment like "Looks good to me" or "LGTM"
+ so we know that someone has looked at it and approved it).
 1. **DO** make sure contributors are following the [contributor guidelines](https://github.com/PowerShell/DscResources/blob/master/CONTRIBUTING.md).
 1. **DO** ask people to resend a pull request, if it targets [the wrong branch](CONTRIBUTING.md#lifecycle-of-a-pull-request).
 1. **DO** require people to write Pester tests for all new/changed functionality.
-1. **DO** wait for the [CI system](CONTRIBUTING.md#appveyor) build to pass for pull requests.
-1. **DO** encourage contributors to refer to issues in PR title/description (e.g. `Fixes #11`, or `Closes #11`). Edit title if necessary.
-1. **DO** encourage contributors to create meaningful titles for all PRs. Edit title if necessary.
+1. **DO** wait for the [CI system](CONTRIBUTING.md#appveyor) build to pass for
+ pull requests.
+1. **DO** encourage contributors to refer to issues in PR title/description
+ (e.g. `Fixes #11`, or `Closes #11`). Edit title if necessary.
+1. **DO** encourage contributors to create meaningful titles for all PRs. Edit
+ title if necessary.
 1. **DO** verify that all contributors are following the [style guidelines](https://github.com/PowerShell/DscResources/blob/master/StyleGuidelines.md).
-1. **DO** verify compliance with any third party code license terms (e.g., requiring attribution, etc.) if the contribution contains third party code.
+1. **DO** verify compliance with any third party code license terms (e.g.,
+ requiring attribution, etc.) if the contribution contains third party code.
 
-1. **DON'T** merge pull requests where the CLA status check (`license/cla`) is pending or the CLA status check is missing (updated by Microsoft CLA bot).
+1. **DON'T** merge pull requests where the CLA status check (`license/cla`) is
+ pending or the CLA status check is missing (updated by Microsoft CLA bot).
 1. **DON'T** merge pull requests to **master** branch.
 1. **DON'T** merge pull requests with a failed CI build.
-1. **DON'T** merge pull requests that do not [include all meaningful changes](CONTRIBUTING.md#lifecycle-of-a-pull-request) under the **Unreleased** section in the repository's `README.md` or `CHANGELOG.md`.
+1. **DON'T** merge pull requests that do not [include all meaningful changes](CONTRIBUTING.md#lifecycle-of-a-pull-request)
+ under the **Unreleased** section in the repository's `README.md` or `CHANGELOG.md`.
 1. **DON'T** merge your own pull requests before they are reviewed by someone else.
- - If there is **no one** else to review your pull request, please wait **24** hours to merge it in case anyone comes along and has a comment.
+ - If there is **no one** else to review your pull request, please wait **24**
+ hours to merge it in case anyone comes along and has a comment.
 
 ## Repeating Tasks
 
@@ -175,30 +187,51 @@ Copyright (c) Microsoft Corporation. All rights reserved.
 
 #### License File contents
 
-The LICENSE file should appear as shown in [LICENSE](https://github.com/PowerShell/DscResources/blob/master/LICENSE), indentation included.
+The LICENSE file should appear as shown in [LICENSE](https://github.com/PowerShell/DscResources/blob/master/LICENSE),
+indentation included.
 
 ## Issue Workflow
 
 1. Someone creates an issue.
-1. A maintainer assigns one of the following labels: ```bug```, ```enhancement```, ```discussion```, ```question```
- 1. In some cases, other special labels may be used (e.g. ```module proposal``` for issues requesting new DSC resource modules in the DscResources repository)
- 1. If the issue is a duplicate of another issue, the maintainer adds the ```duplicate``` label, references the issue this one is a duplicate of, and closes the issue.
- 1. If the issue is external to your module, the maintainer adds the ```external``` label, comments with an explanation of why the issue will not be fixed, and closes the issue.
- 1. If for some other reason an issue should not be fixed, the maintainer adds the ```not fixed``` label, comments with an explanation of why the issue will not be fixed, and closes the issue.
-1. A maintainer assigns the ```help wanted``` label to let contributors know this issue needs someone else to look at it
-1. Once a contributor volunteers to work on the issue, the maintainer removes the ```help wanted``` label, adds the ```in progress``` label, and assigns the issue to the volunteer.
-1. Once issue is fixed, the maintainer removes the ```in progress``` label and closes the issue.
+1. A maintainer assigns one of the following labels: ```bug```, ```enhancement```,
+ ```discussion```, ```question```
+ 1. In some cases, other special labels may be used (e.g. ```module proposal```
+ for issues requesting new DSC resource modules in the DscResources repository)
+ 1. If the issue is a duplicate of another issue, the maintainer adds the ```duplicate```
+ label, references the issue this one is a duplicate of, and closes the issue.
+ 1. If the issue is external to your module, the maintainer adds the ```external```
+ label, comments with an explanation of why the issue will not be fixed, and
+ closes the issue.
+ 1. If for some other reason an issue should not be fixed, the maintainer adds
+ the ```not fixed``` label, comments with an explanation of why the issue will
+ not be fixed, and closes the issue.
+1. A maintainer assigns the ```help wanted``` label to let contributors know this
+ issue needs someone else to look at it
+1. Once a contributor volunteers to work on the issue, the maintainer removes the
+ ```help wanted``` label, adds the ```in progress``` label, and assigns the issue
+ to the volunteer.
+1. Once issue is fixed, the maintainer removes the ```in progress``` label and
+ closes the issue.
 
 ## Pull Request Workflow
 
 1. A contributor opens a pull request.
-2. The contributor ensures that their pull request passes the [CI system](CONTRIBUTING.md#appveyor) build.
- - If the build fails, a maintainer adds the `waiting for code fix` label to the pull request. The contributor can then continue to update the pull request until the build passes.
-2. Once the build passes, the maintainer either reviews the pull request immediately or adds the ```needs review``` label.
-3. A maintainer or trusted contributor reviews the pull request code.
- - If the contributor does not meet the reviewer's standards, the reviewer makes comments. A maintainer then removes the the ```needs review``` label and adds the ```waiting for code fix``` label. The contributor must address the comments and repeat from step 2.
- - If the contributor meets the reviewer's standards, the reviewer comments that they are satisfied. A maintainer then removes the the ```needs review``` label.
-3. Once the code review is completed, a maintainer merges the pull request.
+1. The contributor ensures that their pull request passes the [CI system](CONTRIBUTING.md#appveyor)
+ build.
+ - If the build fails, a maintainer adds the `waiting for code fix` label to the
+ pull request. The contributor can then continue to update the pull request
+ until the build passes.
+1. Once the build passes, the maintainer either reviews the pull request immediately
+ or adds the ```needs review``` label.
+1. A maintainer or trusted contributor reviews the pull request code.
+ - If the contributor does not meet the reviewer's standards, the reviewer makes
+ comments. A maintainer then removes the the ```needs review``` label and adds
+ the ```waiting for code fix``` label. The contributor must address the comments
+ and repeat from step 2.
+ - If the contributor meets the reviewer's standards, the reviewer comments
+ that they are satisfied. A maintainer then removes the the ```needs review```
+ label.
+1. Once the code review is completed, a maintainer merges the pull request.
 
 ### Pull Requests waiting for CLA pass
 
@@ -210,31 +243,49 @@ author should be closed.
 
 ### Abandoned Pull Requests
 
-A pull request with the label `waiting for code fix` or `waiting for author response` for **more than 2 weeks** without word from the author is considered abandoned.
+A pull request with the label `waiting for code fix` or `waiting for author response`
+for **more than 2 weeks** without word from the author is considered abandoned.
 
 In these cases:
 
 1. Ping the author of PR to remind him of pending changes.
- - If the contributor responds, it's no longer an abandoned pull request, proceed as normal.
+ - If the contributor responds, it's no longer an abandoned pull request, proceed
+ as normal.
 1. If the contributor does not respond **within a week**:
- - If the reviewer's comments are very minor, merge the change, fix the code immediately, and create a new PR with the fixes addressing the minor comments.
- - If the changes required to merge the pull request are significant but needed, create a new branch with the changes and open an issue to merge the code into the dev branch. Mention the original pull request ID in the description of the new issue and close the abandoned pull request.
- - If the changes in an abandoned pull request are no longer needed (e.g. due to refactoring of the codebase or a design change), simply close the pull request.
+ - If the reviewer's comments are very minor, merge the change, fix the code
+ immediately, and create a new PR with the fixes addressing the minor comments.
+ - If the changes required to merge the pull request are significant but needed,
+ create a new branch with the changes and open an issue to merge the code into
+ the dev branch. Mention the original pull request ID in the description of
+ the new issue and close the abandoned pull request.
+ - If the changes in an abandoned pull request are no longer needed (e.g. due
+ to refactoring of the codebase or a design change), simply close the pull request.
 
 ## Breaking Changes
+
 Breaking changes may be accepted if they make a resource better.
 Breaking changes usually include:
+
 - Adding a new mandatory parameter
 - Changing an existing parameter
 - Removing an existing parameter
 - Fundamentally changing an existing functionality of a resource
 
 If you need to accept a breaking change in your module please please ensure:
-1. Any issues or PRs associated with the breaking change include the ```breaking change``` label.
-2. At least one of the bullet points in the updated release notes starts with 'BREAKING CHANGE:'.
-3. The title of the PR that includes the breaking change starts with 'BREAKING CHANGE:'.
+
+1. Any issues or PRs associated with the breaking change include the
+ ```breaking change``` label.
+1. At least one of the bullet points in the updated release notes starts with
+ 'BREAKING CHANGE:'.
+1. The title of the PR that includes the breaking change starts with 'BREAKING CHANGE:'.
 
 Upon release, the version of a module with a breaking change will be updated as such:
-* Modules that still have the x... naming are incremented by a full version number if there is a breaking change (2.2.0.0 --> 3.0.0.0). All of these modules are still considered to be in the 'preview' or 'experimental' phase.
-* Modules that have the ...Dsc naming but are still in the 'preview' phase (prior to 1.0.0.0) are incremented only by a sub-version regardless of breaking changes until they are ready to come out of preview (0.3.0.0 --> 0.4.0.0).
-* Modules that have the ...Dsc naming and are out of the 'preview' phase (1.0.0.0 and after) are incremented by a full version number (2.2.0.0 --> 3.0.0.0).
+
+- Modules that still have the x... naming are incremented by a full version number
+ if there is a breaking change (2.2.0.0 --> 3.0.0.0). All of these modules are
+ still considered to be in the 'preview' or 'experimental' phase.
+- Modules that have the ...Dsc naming but are still in the 'preview' phase (prior
+ to 1.0.0.0) are incremented only by a sub-version regardless of breaking changes
+ until they are ready to come out of preview (0.3.0.0 --> 0.4.0.0).
+- Modules that have the ...Dsc naming and are out of the 'preview' phase (1.0.0.0
+ and after) are incremented by a full version number (2.2.0.0 --> 3.0.0.0).

Maintainers.md

@@ -79,10 +79,11 @@ When DSC was originally introduced,
 it was communicated that new modules should be prefixed with an "x"
 to help identify that the work might not be suitable for use in a production environment.
 
-The community has now matured and guidelines exist to hold project maintainers accountable
-through the use of CI process where tests are required and the results are publicly available.
-Anyone that would like to evaluate the quality of a module can view the project documentation,
-code, tests, and test results, to understand if the work is suitable for their environment.
+The community has now matured and guidelines exist to hold project maintainers
+accountable through the use of CI process where tests are required and the results
+are publicly available. Anyone that would like to evaluate the quality of a module
+can view the project documentation, code, tests, and test results, to understand
+if the work is suitable for their environment.
 
 The "x" prefix is no longer required.
 Resources that include the prefix are free to deprecate the convention going forward.

Naming.md

@@ -15,8 +15,8 @@ Prior to listing in DSC Resource repository under [DscResources](https://github.
 ## First step
 
 When you think your resource module is ready for listing in DSC Resource Kit,
-then the first step is to create a new issue using the *New resource module submission* issue
-template. It should include all the information needed to make a successful
+then the first step is to create a new issue using the *New resource module submission*
+issue template. It should include all the information needed to make a successful
 resource module submission (including the above information).
 
 >***Note:** You can look at the template to get the information without submitting