CONTRIBUTING.md

Contributing Guidelines

Welcome to unyt.org!

These guidelines are designed to ensure clarity and foster a positive environment for all contributors. Your participation is invaluable in improving our project. Please adhere to these guidelines to maintain a welcoming and collaborative space.

Note

Please check out our documentation and blog. Feel free to join our projects discord here.

Pull requests, bug reports, and all other forms of contribution on our sub project such as UIX and DATEX are highly encouraged! ❤️

Contents

• Code of Conduct
• Asking Questions
• Opening an Issue
  • Reporting Security Issues
  • Bug Reports and Other Issues
• Feature Requests
• Submitting Pull Requests
• Writing Commit Messages
• Code Review
• Coding Style

📖 Code of Conduct

Please review our Code of Conduct. Any behavior violating this code will not be tolerated.

💡 Asking Questions

If you have questions, please refer to our Discord Support. While GitHub issues are not for debugging individual projects, they are suitable for reporting bugs and suggesting features. For legal inquiries to unyt.org e.V., media inquiries or any other business inquiries you can contact our team via support@unyt.org.

📥 Opening an Issue

Before creating an issue, check if you are using the latest version and branch of the project. If you are not up-to-date, see if updating fixes your issue first. Always include the project version number and local setup information in your issues.

• Open an issue for UIX
• Open an issue for DATEX
• Open an issue for unyt.land

🔒 Reporting Security Issues

Please review our Security Policy and do not file a public issue for critical security vulnerabilities. You can reach our security team via security@unyt.org. Download our PGP key here.

• Report an UIX security issue
• Report a DATEX security issue

🪲 Bug Reports and Other Issues

To contribute, submit a detailed issue when encountering a problem. Ensure it includes necessary information like steps to reproduce, stack traces, and screenshots.

• Review the documentation and our blog before creating an issue.
• Avoid opening duplicate issues. Search existing ones and provide additional information if needed.
• Use reactions to express support for existing issues.
• Complete the provided issue template thoroughly, including relevant details.

💌 Feature Requests

We do really love and more than that - rely on your feature requests! Please keep in mind that we cannot guarantee the acceptance of your feature request. Ensure your request aligns with the project scope, unyt.org vision and provide (technical) implementation details if possible.

• Avoid duplicating feature requests. Comment on existing ones if similar.
• Complete the provided feature request template.

🔁 Submitting Pull Requests

We love pull requests! Before forking the repo and creating a pull request, it is the best to first open an issue to discuss the changes and needs.

• Start with smaller pull requests for easier review.
• Coordinate large changes with maintainers.
• Prioritize code clarity and follow existing conventions.
• Include tests, update documentation, and the CHANGELOG.
• Resolve merge conflicts and address CI failures promptly.

📝 Writing Commit Messages

Please follow these guidelines for good commit messages:

• Separate subject and body with a blank line.
• Limit subject line to 50 characters, using imperative mood.
• Explain "why" in the body, not "what" or "how."
• Wrap body at less than 100 characters.
• Mention relevant component name, username (@maintainer) and issues (#42).

✅ Code Review

• Focus on code, not the author.
• Don't take critiques personally.
• Strive for quality and learn from mistakes.
• Note any guideline violations kindly.

💅 Coding Style

Consistency is the most important. Following the existing style, formatting, and naming conventions of the file you are modifying and of the overall project. Failure to do so will result in a prolonged review process that has to focus on updating the superficial aspects of your code, rather than improving its functionality and performance.

📱 TypeScript

• Constants shall be uppercase and seperated with underscore (const MY_CONST = 42)
• Properties shall follow camel case naming convention (myProp)
• Method names shall follow camel case naming convention (myFunction() {})

---

_{© unyt 2024 • unyt.org}