A good pull request

Every contribution has to come with:

• Before starting coding, you should open an issue on the UI for UWP Issues page and start discussing with the community to see if your idea/feature is interesting enough.
• 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. Once validated your documentation will be visible here
• Adding a sample application in the SDKExamples app 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.
• Test your code at least with SDK 10586, SDK 14393 and SDK 15063.
• 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.
• 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:
  • 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)
  • What: A summary of the proposed solution
  • How: A description of how this solution solves the problem, in more detail than item #2
  • Any additional discussion on possible problems this might introduce, questions that you have related to the changes, etc.
• (optional) When you've completed your work on a topic branch, you may squash your work down into fewer commits to make the merge process easier. For information on squashing via an interactive rebase, see the rebase documentation on GitHub

PR has to be validated by at least two core members before being merged.