Welcome

Welcome to the Contributing page of the Windows Community Toolkit 🎉🎉

We are beyond excited for you to participate in the community. It is because of valuable contributors like you that keep the Windows Community Toolkit thriving. Whether you fix any small bug or a major one, any contribution will go a long way to enhance the toolkit.

Open collaboration means leveraging the unique strengths, contributions, and experiences of each community member, and your contributions make the Community Toolkit more reliable and useful for everyone.

If you require guidance using the toolkit or building for it, our team is available to discuss submitting the PR, reviewing your work, or answering any project related questions that you are unclear about.

Getting Started

See Getting started to get started with the Windows Community Toolkit. This guide will help you to understand the process of cloning the repository, editing a component, running the sample app, and creating a new component.

Feedback and Requests

Please use GitHub Issues for bug reports and enhancements. For new feature requests, see Community Toolkit Labs.

For general questions and support, please use Stack Overflow where questions should be tagged with the tag windows-community-toolkit.

You can also chat with Community Toolkit maintainers or other community members in our Windows App Community Discord channel.

About Windows Community Toolkit

The driving principle of the Windows Community Toolkit is maintaining simplicity for both maintainers and consumers of toolkit components.

• Simplicity and a low barrier to entry are must-have features of every API. With simplicity comes maintainability, extensibility, ease of use, and more.

• If you have any second thoughts about the complexity of the design, it is almost always much better to cut the feature from the current release and spend more time to get the design right for the next release.

• You can add to or extend an API, but once you ship a stable release you cannot remove from or edit it without breaking consumer code. Take time to consider the use cases you need to cover now, and those you may need to cover in the future, and design your extensibility accordingly.

• It is better to ship a smaller, simpler API and extend it later than to ship a larger, more complex API and have to maintain it forever.

• Code should be organized and easy to understand for developers who are new to the toolkit.

• Features should be minimal and well-separated from other features.

• The process for maintainers to build new components, add new features, fix bugs, write tests, create component samples and docs, and ship new releases should be straightforward and well-documented.

See also Principles for more.