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
{{ message }}
This repository was archived by the owner on Nov 28, 2024. It is now read-only.
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,7 +27,7 @@ Every contribution has to come with:
27
27
* A good documentation should be provided for every added API - do not expect that your API is so well designed that it needs no documentation. The documentation has a separate repository that could be found [here](https://github.com/telerik/uwp-docs). Once validated your documentation will be visible [here](http://docs.telerik.com/devtools/universal-windows-platform/introduction-uwp)
28
28
* Adding a sample application in the [SDKExamples app](https://github.com/telerik/UI-For-UWP/tree/master/SDKExamples.UWP) that demonstrates new functionality is a sign for good pull request as well. The sample should be applicable and to demonstrate a real case scenarios.
29
29
* Test your code at least with SDK 10586, SDK 14393 and SDK 15063.
30
-
* PR has to target master branch. However, the work you are doing for your pull request should not be done in the master branch of your forked repository. Create a topic branch for your work - always create a branch for your work from the "master" branch. This allows you to isolate the work you are doing from other changes that may be happening.
30
+
* PR has to target development branch. However, the work you are doing for your pull request should not be done in the development branch of your forked repository. Create a topic branch for your work - always create a branch for your work from the "development" branch. This allows you to isolate the work you are doing from other changes that may be happening.
31
31
* It is very important to provide a meaningful description with your pull requests that alter any code. A good format for these descriptions will include:
32
32
* Why: The problem you are facing (in as much detail as is necessary to describe the problem to someone who doesn't know anything about the system you're building)
0 commit comments