You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+24-7Lines changed: 24 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -109,14 +109,30 @@ Once the team have approved an issue/spec, development can proceed. If no develo
109
109
110
110
### Fork, Clone, Branch and Create your PR
111
111
112
-
Once you've discussed your proposed feature/fix/etc. with a team member, and you've agreed an approach or a spec has been written and approved, it's time to start development:
112
+
Once you've discussed your proposed feature/fix/etc. with a team member, and you've agreed an approach or a spec has been written and approved, it's time to start development. There are two flows you can follow depending on the proposed feature or fix.
113
+
114
+
If you're feature (or module) has not yet been created, follow these steps:
115
+
116
+
1. Fork the repository if you haven't already.
117
+
2. Clone your fork locally.
118
+
3. Open a PowerShell terminal session and execute: `.\utilities\tools\New-DscResourceModule.ps1 -DscResourceModule '<moduleName>' -Description 'DSC Resource for <description>'`
119
+
4. Work on your changes and write tests.
120
+
5. Build and test to see if it works.
121
+
6. Create & push a feature branch.
122
+
7. Create a [Draft Pull Request (PR)](https://github.blog/2019-02-14-introducing-draft-pull-requests/).
123
+
8. If you are finished with your changes and you want a review, change the state.
124
+
125
+
> [!TIP]
126
+
> Don't forget to add the `DscResourcesToExport` and `Tags`.
127
+
128
+
When you are working on a fix or you want to add additional features to an existing module, you can follow the below steps:
113
129
114
130
1. Fork the repository if you haven't already.
115
-
1. Clone your fork locally.
116
-
1. Create & push a feature branch.
117
-
1. Create a [Draft Pull Request (PR)](https://github.blog/2019-02-14-introducing-draft-pull-requests/).
118
-
1. Work on your changes.
119
-
1. Build and see if it works.
131
+
2. Clone your fork locally.
132
+
3. Work on your fix or feature, and _optionally_ write tests
133
+
4. Build and test to see if it works.
134
+
5. Create & push a feature branch.
135
+
6. Create a [Pull Request (PR)](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request) when you are finished with your changes
120
136
121
137
### Testing
122
138
@@ -126,7 +142,8 @@ Testing is a key component in the development workflow.
126
142
127
143
When you'd like the team to take a look, (even if the work is not yet fully-complete), mark the Draft PR as 'Ready For Review' so that the team can review your work and provide comments, suggestions, and request changes. It may take several cycles, but the end result will be solid, testable, conformant code that is safe for us to merge.
128
144
129
-
> ⚠ Remember: **changes you make may affect both the Windows Package Manager and the schema support implemented in our validation pipelines!** Because of this, we will treat community PR's with the same level of scrutiny and rigor as commits submitted to the official Windows source by team members and partners.
145
+
> [!CAUTION]
146
+
> Remember: **changes you make may affect both the Windows Package Manager and the schema support implemented in our validation pipelines!** Because of this, we will treat community PR's with the same level of scrutiny and rigor as commits submitted to the official Windows source by team members and partners.
0 commit comments