Use the channel that matches the kind of feedback you have. Keeping discussions in the right place makes the project easier to maintain and easier to search later.
Bugs and Regressions
Open a GitHub issue when something is broken, misleading, or inconsistent. Useful reports usually include:
- the component or page involved
- what you expected to happen
- what actually happened
- a minimal reproduction or screenshot when relevant
Questions and Discussion
If you are unsure whether something is a bug, or you want to talk through a pattern before opening an issue, use the project’s discussion channel if available. Community discussion is a better fit for open-ended API ideas, naming questions, and requests for guidance.
Sharing Improvements
If you adapt a loading-ui component into a stronger pattern, that is useful project feedback. Examples, accessibility improvements, and docs fixes are all valid contributions, not just new components.
Expectations
Keep discussion technical, respectful, and specific. Critique the implementation, not the person. The fastest way to get useful help is to be concrete about the problem you are solving.
Want to contribute directly?
Read Contributing for the expected workflow before opening a pull request.
