11# Contribution Guidelines
22
3- We welcome many kinds of community contributions to this project! Whether it's a feature implementation,
4- bug fix, or a good idea, please create an issue so that we can discuss it. It is not necessary to create an
5- issue before sending a pull request but it may speed up the process if we can discuss your idea before
3+ We welcome many kinds of community contributions to this project! Whether it's a feature implementation,
4+ bug fix, or a good idea, please create an issue so that we can discuss it. It is not necessary to create an
5+ issue before sending a pull request but it may speed up the process if we can discuss your idea before
66you start implementing it.
77
8- Because this project exposes a couple different public APIs, we must be very mindful of any potential breaking
9- changes. Some contributions may not be accepted if they risk introducing breaking changes or if they
8+ Because this project exposes a couple different public APIs, we must be very mindful of any potential breaking
9+ changes. Some contributions may not be accepted if they risk introducing breaking changes or if they
1010don't match the goals of the project. The core maintainer team has the right of final approval over
11- any contribution to this project. However, we are very happy to hear community feedback on any decision
11+ any contribution to this project. However, we are very happy to hear community feedback on any decision
1212so that we can ensure we are solving the right problems in the right way.
1313
1414** NOTE** : If you believe there is a security vulnerability, please see [ Security Reporting] ( #security-reporting ) .
@@ -31,7 +31,7 @@ Here's a high level list of guidelines to follow to ensure your code contributio
3131- Follow established guidelines for commit hygiene
3232- Write unit tests to validate new features and bug fixes
3333- Ensure that the 'Release' build and unit tests pass locally
34- - Ensure that the AppVeyor build passes for your change
34+ - Ensure that the Azure DevOps build passes for your change
3535- Respond to all review feedback and final commit cleanup
3636
3737### Practice Good Commit Hygiene
@@ -44,46 +44,46 @@ so that your commits provide a good history of the changes you are making. To b
4444 Commit messages should be clearly written so that a person can look at the commit log and understand
4545 how and why a given change was made. Here is a great model commit message taken from a [ blog post
4646 by Tim Pope] ( http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html ) :
47-
47+
4848 Capitalized, short (50 chars or less) summary
49-
49+
5050 More detailed explanatory text, if necessary. Wrap it to about 72
5151 characters or so. In some contexts, the first line is treated as the
5252 subject of an email and the rest of the text as the body. The blank
5353 line separating the summary from the body is critical (unless you omit
5454 the body entirely); tools like rebase can get confused if you run the
5555 two together.
56-
56+
5757 Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
5858 or "Fixes bug." This convention matches up with commit messages generated
5959 by commands like git merge and git revert.
60-
60+
6161 Further paragraphs come after blank lines.
62-
62+
6363 - Bullet points are okay, too
64-
64+
6565 - Typically a hyphen or asterisk is used for the bullet, followed by a
6666 single space, with blank lines in between, but conventions vary here
67-
67+
6868 - Use a hanging indent
69-
69+
7070 A change that fixes a known bug with an issue filed should use the proper syntax so that the [ issue
71- is automatically closed] ( https://help.github.com/articles/closing-issues-via-commit-messages/ ) once
71+ is automatically closed] ( https://help.github.com/articles/closing-issues-via-commit-messages/ ) once
7272 your change is merged. Here's an example of what such a commit message should look like:
73-
73+
7474 Fix #3: Catch NullReferenceException from DoThing
75-
75+
7676 This change adds a try/catch block to catch a NullReferenceException that
7777 gets thrown by DoThing [...]
7878
7979- ** Squash your commits**
8080
81- If you are introducing a new feature but have implemented it over multiple commits,
82- please [ squash those commits] ( http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html )
81+ If you are introducing a new feature but have implemented it over multiple commits,
82+ please [ squash those commits] ( http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html )
8383 into a single commit that contains all the changes in one place. This especially applies to any "oops"
84- commits where a file is forgotten or a typo is being fixed. Following this approach makes it a lot easier
84+ commits where a file is forgotten or a typo is being fixed. Following this approach makes it a lot easier
8585 to pull those changes to other branches or roll back the change if necessary.
86-
86+
8787- ** Keep individual commits for larger changes**
8888
8989 You can certainly maintain individual commits for different phases of a big change. For example, if
@@ -96,10 +96,10 @@ so that your commits provide a good history of the changes you are making. To b
9696If you're adding a new feature to the project, please make sure to include adequate [ xUnit] ( http://xunit.github.io/ )
9797tests with your change. In this project, we have chosen write out unit tests in a way that uses the
9898actual PowerShell environment rather than extensive interface mocking. This allows us to be sure that
99- our features will work in practice.
99+ our features will work in practice.
100100
101- We do both component-level and scenario-level testing depending on what code is being tested. We don't
102- expect contributors to test every possible edge case. Testing mainline scenarios and the most common
101+ We do both component-level and scenario-level testing depending on what code is being tested. We don't
102+ expect contributors to test every possible edge case. Testing mainline scenarios and the most common
103103failure scenarios is often good enough.
104104
105105We are very happy to accept unit test contributions for any feature areas that are more error-prone than
@@ -118,15 +118,15 @@ on this check so that our project will always have good generated documentation.
118118
119119- ** Create your pull request**
120120
121- Use the [ typical process] ( https://help.github.com/articles/using-pull-requests/ ) to send a pull request
121+ Use the [ typical process] ( https://help.github.com/articles/using-pull-requests/ ) to send a pull request
122122 from your fork of the project. In your pull request message, please give a high-level summary of the
123123 changes that you have made so that reviewers understand the intent of the changes. You should receive
124124 initial comments within a day or two, but please feel free to ping if things are taking longer than
125125 expected.
126126
127127- ** The build and unit tests must run green**
128128
129- When you submit your pull request, our automated build system on AppVeyor will attempt to run a
129+ When you submit your pull request, our automated build system on Azure DevOps will attempt to run a
130130 Release build of your changes and then run all unit tests against the build. If you notice that
131131 any of your unit tests have failed, please fix them by creating a new commit and then pushing it
132132 to your branch. If you see that some unrelated test has failed, try re-running the build for your
@@ -137,15 +137,15 @@ on this check so that our project will always have good generated documentation.
137137
138138 If the reviewers ask you to make changes, make them as a new commit to your branch and push them so
139139 that they are made available for a final review pass. Do not rebase the fixes just yet so that the
140- commit hash changes don't upset GitHub's pull request UI.
141-
140+ commit hash changes don't upset GitHub's pull request UI.
141+
142142- ** If necessary, do a final rebase**
143143
144144 Once your final changes have been accepted, we may ask you to do a final rebase to have your commits
145145 so that they follow our commit guidelines. If specific guidance is given, please follow it when
146- rebasing your commits. Once you do your final push and we see the AppVeyor build pass, we will
146+ rebasing your commits. Once you do your final push and we see the Azure DevOps build pass, we will
147147 merge your changes!
148-
148+
149149### Security Reporting
150150
151151If you believe that there is a security vulnerability in the PowerShell extension for VSCode,
0 commit comments