Kaynağa Gözat

Fix typos and wording

akarnokd 5 yıl önce
ebeveyn
işleme
c0255e98e7

+ 4 - 4
.github/ISSUE_TEMPLATE/issue_ix.md

@@ -1,6 +1,6 @@
 ---
 name: Issue report for Ix
-about: Creates an issue report regarding a bug, question of feature request for Ix.NET
+about: Creates an issue report regarding a bug, question or feature request for Ix.NET
 title: ''
 labels: '[area] Ix'
 assignees: ''
@@ -24,7 +24,7 @@ and/or provide workarounds. Note that certain (odd) behaviors are by design and
 
 > What is the actual outcome?
 
-> What is the stacktrace of the exeption(s) if any?
+> What is the stacktrace of the exception(s) if any?
 
 > Do you have a code snippet or project that reproduces the problem?
 
@@ -59,14 +59,14 @@ without too much inconvenience. Please consider hosting such factory methods out
 b) **New instance method/operator.** The .NET world features extension methods which gives the flexibility to have fluent API expansions in
 your local project or any third party library. Please consider hosting such methods outside dotnet/reactive too.
 
-c) **Support for or bridge to other 1st or 3rd party components.** These are generally considered on a specific case-by-case basis but generally,
+c) **Support for or bridge to other 1st or 3rd party components.** These are considered on a specific case-by-case basis but generally,
 please consider hosting such support/bridge code outside dotnet/reactive.
 
 d) **New reactive/interactive base type or concept.** Components requiring changes or introduction of new protocols (for example, flow control,
 item lifecycle, async) are generally better suited for their own 3rd party library hosting and interoperation should be provided, via the standard
 types mentioned above, there.
 
-e) **Behavior change on an existing operator.** Such changes involve a lot of risks for existing users, therefore, usually it is better to introduce
+e) **Behavior change on an existing operator.** Such changes involve a lot of risks for existing users, therefore, usually, it is better to introduce
 a completely new component or operator, for which see points a)..d) again.
 
 Considering the points above, please describe the feature or behavior you would like dotnet/reactive included:

+ 4 - 4
.github/ISSUE_TEMPLATE/issue_rx.md

@@ -1,6 +1,6 @@
 ---
 name: Issue report for Rx
-about: Creates an issue report regarding a bug, question of feature request for Rx.NET
+about: Creates an issue report regarding a bug, question or feature request for Rx.NET
 title: ''
 labels: '[area] Rx'
 assignees: ''
@@ -22,7 +22,7 @@ and/or provide workarounds. Note that certain (odd) behaviors are by design and
 
 > What is the actual outcome?
 
-> What is the stacktrace of the exeption(s) if any?
+> What is the stacktrace of the exception(s) if any?
 
 > Do you have a code snippet or project that reproduces the problem?
 
@@ -56,14 +56,14 @@ without too much inconvenience. Please consider hosting such factory methods out
 b) **New instance method/operator.** The .NET world features extension methods which gives the flexibility to have fluent API expansions in
 your local project or any third party library. Please consider hosting such methods outside dotnet/reactive too.
 
-c) **Support for or bridge to other 1st or 3rd party components.** These are generally considered on a specific case-by-case basis but generally,
+c) **Support for or bridge to other 1st or 3rd party components.** These are considered on a specific case-by-case basis but generally,
 please consider hosting such support/bridge code outside dotnet/reactive.
 
 d) **New reactive/interactive base type or concept.** Components requiring changes or introduction of new protocols (for example, flow control,
 item lifecycle, async) are generally better suited for their own 3rd party library hosting and interoperation should be provided, via the standard
 types mentioned above, there.
 
-e) **Behavior change on an existing operator.** Such changes involve a lot of risks for existing users, therefore, usually it is better to introduce
+e) **Behavior change on an existing operator.** Such changes involve a lot of risks for existing users, therefore, usually, it is better to introduce
 a completely new component or operator, for which see points a)..d) again.
 
 Considering the points above, please describe the feature or behavior you would like dotnet/reactive included:

+ 4 - 4
.github/PULL_REQUEST_TEMPLATE/pr_ix.md

@@ -1,13 +1,13 @@
 ---
 name: Pull request for Ix
-about: Creates a Pull request regarding a bug, enhancement of feature request for Ix.NET
+about: Creates a Pull request regarding a bug, enhancement or feature request for Ix.NET
 title: ''
 labels: '[area] Ix'
 assignees: ''
 ---Hello and thank you for contributing to dotnet/reactive. Before you proceed by creating a pull request (PR):
 
 > Please make sure your contribution is in line with the project's [licensing model](https://github.com/dotnet/reactive/blob/master/LICENSE) and
-your empoyment allows you to contribute to open source.
+your employment allows you to contribute to open source.
 
 > Please sign the [Contributor License Agreement](https://cla.dotnetfoundation.org/dotnet/reactive?pullRequest=1101) in case the CLA bot asks you
 for being a new contributor.
@@ -43,7 +43,7 @@ What is the nature of your contribution?
 #### Feature request
 
 > We strongly recommend opening an [issue](https://github.com/dotnet/reactive/issues) first to discuss the nature and impact of the request first.
-> If such issue already exist, please check if there was a consensus and approval for accepting a contribution.
+> If such an issue already exists, please check if there was a consensus and approval for accepting a contribution.
 
 > Please describe what request is about, how it works in general and what possible corner cases it or the user should consider.
 > Please include some basic usage examples of the important components and/or overloads.
@@ -51,6 +51,6 @@ What is the nature of your contribution?
 
 > Please reference the related issue(s) to the original issue report (example: `Resolves #X`).
 
-> Please include unit tests that verifiy the behavior of the new feature. Please make sure the code coverage is reasonably high with the new code.
+> Please include unit tests that verify the behavior of the new feature. Please make sure the code coverage is reasonably high with the new code.
 > Depending on the feature, you may want to include actual multi-threaded test cases to verify the correct async behavior, however,
 > please be mindful of the time such tests take and try to stay under a few seconds.

+ 5 - 5
.github/PULL_REQUEST_TEMPLATE/pr_rx.md

@@ -1,6 +1,6 @@
 ---
 name: Pull request for Rx
-about: Creates a Pull request regarding a bug, enhancement of feature request for Rx.NET
+about: Creates a Pull request regarding a bug, enhancement or feature request for Rx.NET
 title: ''
 labels: '[area] Rx'
 assignees: ''
@@ -8,7 +8,7 @@ assignees: ''
 Hello and thank you for contributing to dotnet/reactive. Before you proceed by creating a pull request (PR):
 
 > Please make sure your contribution is in line with the project's [licensing model](https://github.com/dotnet/reactive/blob/master/LICENSE) and
-your empoyment allows you to contribute to open source.
+your employment allows you to contribute to open source.
 
 > Please sign the [Contributor License Agreement](https://cla.dotnetfoundation.org/dotnet/reactive?pullRequest=1101) in case the CLA bot asks you
 for being a new contributor.
@@ -32,7 +32,7 @@ What is the nature of your contribution?
 #### Enhancement
 
 > Please consider opening an [issue](https://github.com/dotnet/reactive/issues) first to discuss the kind and impact of the enhancement first,
-> if such issue doesn't exist yet.  Also please check if there was a consensus about accepting such an enhancement.
+> if such an issue doesn't exist yet.  Also please check if there was a consensus about accepting such an enhancement.
 
 > Please describe how, what and why the enhancement is implemented.
 > Practically, you are writing these descriptions for the search engines so others can find the change details easier.
@@ -44,7 +44,7 @@ What is the nature of your contribution?
 #### Feature request
 
 > We strongly recommend opening an [issue](https://github.com/dotnet/reactive/issues) first to discuss the nature and impact of the request first.
-> If such issue already exist, please check if there was a consensus and approval for accepting a contribution.
+> If such an issue already exists, please check if there was a consensus and approval for accepting a contribution.
 
 > Please describe what request is about, how it works in general and what possible corner cases it or the user should consider.
 > Please include some basic usage examples of the important components and/or overloads.
@@ -52,6 +52,6 @@ What is the nature of your contribution?
 
 > Please reference the related issue(s) to the original issue report (example: `Resolves #X`).
 
-> Please include unit tests that verifiy the behavior of the new feature. Please make sure the code coverage is reasonably high with the new code.
+> Please include unit tests that verify the behavior of the new feature. Please make sure the code coverage is reasonably high with the new code.
 > Depending on the feature, you may want to include actual multi-threaded test cases to verify the correct async behavior, however,
 > please be mindful of the time such tests take and try to stay under a few seconds.