Maintainers.md

DSC Resource Kit Maintainers

Maintainers are trusted contributors with knowledge in a resource module domain who have write access 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.

Table of Contents

• Current Maintainers
• Rules
• Repeating Tasks
• Issue Workflow
• Pull Request Workflow
  • Abandoned Pull Requests
• Breaking Changes

Current Maintainers

Being a maintainer is a time-consuming task! If you find you no longer have the time for this role, please let us know. That helps us keep contributors up-to-date on what to expect for certain repositories. If you should be on this list but are not, please tag @kwirkykat in an issue or send @katiedsc a private message on Twitter.

Resource modules listed in the DSC Resource Kit, except PSDscResources, are not created or maintained by Microsoft. These modules are maintained by community members. Issues or questions relating to these resource modules should be raised within the resource module's repository.

All repositories without dedicated maintainers are maintained by the current DSC Resource Kit owners, Katie Keim (@kwirkykat) and Mariah Breakey (@mbreakey3).

Repository	Maintainer(s)
ActiveDirectoryCSDsc	Daniel Scott-Raynsford (@PlagueHO) Jason Ryberg (@devopsjesus)
ActiveDirectoryDsc	Johan Ljunggren (@johlju) Jan-Hendrik Peters (@nyanhp) Jason Ryberg (@devopsjesus) Ryan Christman (@rchristman89) Simon Heather (@x-guardian)
AuditPolicyDsc	Adam Haynes (@athaynes)
CertificateDsc	Daniel Scott-Raynsford (@PlagueHO)
ComputerManagementDsc	Tyson Hayes (@tysonjhayes) Daniel Scott-Raynsford (@PlagueHO)
DFSDsc	Daniel Scott-Raynsford (@PlagueHO)
DscResources	Katie Keim (@kwirkykat) Zachary Alexander (@zjalexander)
DscResource.Tests	Katie Keim (@kwirkykat) Mariah Breakey (@mbreakey3)
FileContentDsc	Daniel Scott-Raynsford (@PlagueHO)
FSRMDsc	Daniel Scott-Raynsford (@PlagueHO)
iSCSIDsc	Daniel Scott-Raynsford (@PlagueHO)
NetworkingDsc	Tyson Hayes (@tysonjhayes) Daniel Scott-Raynsford (@PlagueHO) Mike Beggs (@39Delta)
OfficeOnlineServerDsc	Nik Charlebois (@NikCharlebois)
PSDscResources	Mariah Breakey (@mbreakey3) Katie Keim (@kwirkykat) Mike Hendrickson (@mhendric) Daniel Scott-Raynsford (@PlagueHO)
SecurityPolicyDsc	Jason Walker (@jcwalker)
SharePointDsc	Yorick Kuijs (@ykuijs) Nik Charlebois (@NikCharlebois)
SqlServerDsc	Johan Ljunggren (@johlju)
StorageDsc	Daniel Scott-Raynsford (@PlagueHO)
SystemLocaleDsc	DEPRECATED - Migrated to ComputerManagementDsc
WmiNamespaceSecurityDsc	---
WSManDsc	Daniel Scott-Raynsford (@PlagueHO)
xAzure	Chase Wilson (@chasewilson) Jason Ryberg (@devopsjesus)
xAzurePack	---
xBitlocker	Mike Hendrickson (@mhendric)
xChrome	---
xCredSSP	---
xDatabase	---
xDefender	DEPRECATED - Replaced by WindowsDefenderDsc. Note: WindowsDefenderDsc is not part of DSC Resource Kit.
xDhcpServer	Mike Beggs (@39Delta)
xDisk	DEPRECATED - Replaced by StorageDsc
xDismFeature	---
xDnsServer	Jason Patton (@japatton) Chris Dent (@indented-automation)
xDscDiagnostics	---
xDSCResourceDesigner	---
xExchange	Mike Hendrickson (@mhendric)
xFailOverCluster	Johan Ljunggren (@johlju)
xFirefox	Chase Wilson (@chasewilson)
xHyper-V	Anthony Romano (@aromano2) Matthew Collera (@mcollera)
xInternetExplorerHomePage	---
xJea	---
xMySql	---
xPendingReboot	DEPRECATED - Migrated to ComputerManagementDsc
xPhp	---
xPowerShellExecutionPolicy	DEPRECATED - Migrated to ComputerManagementDsc
xPSDesiredStateConfiguration	Mike Hendrickson (@mhendric) Daniel Scott-Raynsford (@PlagueHO)
xRemoteDesktopAdmin	DEPRECATED - Migrated to ComputerManagementDsc
xRemoteDesktopSessionHost	Leo D'Arcy (@ld0614)
xRobocopy	---
xSafeHarbor	---
xSCDPM	Leo D'Arcy (@ld0614)
xSCOM	Leo D'Arcy (@ld0614)
xSCSMA	Jason Ryberg (@devopsjesus)
xSCSPF	---
xSCSR	---
xSCVMM	Jan-Hendrik Peters (@nyanhp)
xSmbShare	DEPRECATED - Migrated to ComputerManagementDsc
xSqlPs	DEPRECATED - Replaced by SqlServerDsc
xSystemSecurity	---
xTimeZone	DEPRECATED - Migrated to ComputerManagementDsc
xWebAdministration	Tyson Hayes (@tysonjhayes) Reggie Gibson (@regedit32)
xWebDeploy	---
xWindowsEventForwarding	---
xWindowsRestore	---
xWindowsUpdate	---
xWinEventLog	DEPRECATED - Migrated to ComputerManagementDsc
xWordPress	---

Rules

If you are maintainer, please follow these rules:

1. DO take care of pull requests in a timely manner.

2. DO ensure that each contributor has signed a valid Contributor License Agreement (CLA).

3. 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).

4. DO make sure contributors are following the contributor guidelines.

5. DO ask people to resend a pull request, if it targets the wrong branch.

6. DO require people to write Pester tests for all new/changed functionality.

7. DO wait for the CI system build to pass for pull requests.

8. DO encourage contributors to refer to issues in PR title/description (e.g. Fixes #11, or Closes #11). Edit title if necessary.

9. DO encourage contributors to create meaningful titles for all PRs. Edit title if necessary.

10. DO verify that all contributors are following the style guidelines.

11. DO verify compliance with any third party code license terms (e.g., requiring attribution, etc.) if the contribution contains third party code.

12. 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).

13. DON'T merge pull requests to master branch.

14. DON'T merge pull requests with a failed CI build.

15. DON'T merge pull requests that do not include all meaningful changes under the Unreleased section in the repository's README.md or CHANGELOG.md.

16. 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.

Repeating Tasks

If you are a maintainer these are the repeating tasks that need to be done regularly.

Check copyright information

Each year, before that year's first DSC Resource Kit release, the copyright information should be updated in the module's module manifest (the .psd1 file) and in the LICENSE file.

Module manifest

This is how the copyright information looks for the year 2017.

# Copyright statement for this module
Copyright = '(c) 2017 Microsoft Corporation. All rights reserved.'

From the beginning of October 2018, the copyright information should be updated as below.

# Copyright statement for this module
Copyright = '(c) Microsoft Corporation. All rights reserved.'

License

This is how the copyright information looks for the year 2017.

Copyright (c) 2017 Microsoft Corporation

From the beginning of October 2018, the copyright information should be updated as below.

Copyright (c) Microsoft Corporation. All rights reserved.

License File contents

The LICENSE file should appear as shown in LICENSE, indentation included.

Issue Workflow

1. Someone creates an issue.
2. 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)
   2. 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.
   3. 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.
   4. 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.
3. A maintainer assigns the help wanted label to let contributors know this issue needs someone else to look at it
4. 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.
5. 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 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.
3. Once the build passes, the maintainer either reviews the pull request immediately or adds the needs review label.
4. 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.
5. Once the code review is completed, a maintainer merges the pull request.

Pull Requests waiting for CLA pass

Please remind the contributor that a PR cannot be reviewed or merged without the CLA being signed. A pull request pull requests that haven't passes the status check license/cla (from the Microsoft CLA bot) for more than 2 weeks without word from the 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.

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.
2. 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.

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:'.

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).