Contributing.md

Contributing to the Sample

• Questions
• Issues or Bugs
• Submitting a pull request
• Quality assurance for pull requests for XAML controls
• General rules
• Naming conventions
• Documentation
• Files and folders

Questions

Please do not open issues for general support questions and keep our GitHub issues for bug reports and feature requests.

Found a Bug?

If you find a bug, you can help us by submitting an issue. Even better, you can submit a Pull Request with a fix.

Submitting a pull request

For every contribution, you must:

• test your code with the supported SDKs
• follow the quality guidance, general rules and naming convention
• target master branch (or an appropriate release branch if appropriate for a bug fix)

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

Quality assurance for pull requests

We encourage developers to follow the following guidances when submitting pull requests:

• Your UI must be usable and efficient with keyboard only
• Tab order must be logical
• Action must be triggered when hitting Enter key
• Do not use custom colors but instead rely on theme colors so high contrasts themes can be used with your control
• Add AutomationProperties.Name on all controls to define what the controls purpose (Name is minimum, but there are some other things too that can really help the screen reader).
• Don't use the same Name on two different elements unless they have different control types
• Use Narrator Dev mode (Launch Narrator [WinKey+Enter], then CTRL+F12) to test the screen reader experience. Is the information sufficient, meaningful and helps the user navigate and understand your UI
• Ensure that you have run your xaml file changes through Xaml Styler (version 2.3+), which can be downloaded from here. Do not worry about the settings for this as they are set at the project level (settings.xamlstyler).

You can find more information about these topics here

This is to help as part of our effort to build an accessible toolkit (starting with 1.2)

General rules

• DO NOT require that users perform any extensive initialization before they can start programming basic scenarios.
• DO provide good defaults for all values associated with parameters, options, etc.
• DO ensure that APIs are intuitive and can be successfully used in basic scenarios without referring to the reference documentation.
• DO communicate incorrect usage of APIs as soon as possible.
• DO design an API by writing code samples for the main scenarios. Only then, you define the object model that supports those code samples.
• DO declare static dependency properties at the top of their file.
• DO NOT seal controls.
• DO use extension methods over static methods where possible.

Naming conventions

• We are following the coding guidelines of .NET Core Foundational libraries.

Documentation

• DO NOT expect that your API is so well designed that it needs no documentation. No API is that intuitive.
• DO provide great documentation with all APIs.
• DO use readable and self-documenting identifier names.
• DO use consistent naming and terminology.
• DO provide strongly typed APIs.
• DO use verbose identifier names.

Files and folders

• DO associate no more than one class per file.
• DO use folders to group classes based on features.