Skip to content

Latest commit

 

History

History
57 lines (37 loc) · 3.05 KB

CONTRIBUTING.md

File metadata and controls

57 lines (37 loc) · 3.05 KB

Contributing Guidelines

Pull requests, bug reports, and all other forms of contribution are welcomed and highly encouraged! 🎉

TOC

Code of Conduct

Code of Conduct

💌 Feature Request

Feature requests are welcome! We will consider all feature request, but we cannot guarantee your feature request will be accept.However, you are welcome to submit a pull request to help!

  • Do not open a duplicate feature request. Search for existing feature requests first. If you find your feature (or one very similar) previously requested, comment on that issue.
  • Fully complete the provided issue template. The feature request template asks for all necessary information for us to begin a productive conversation.
  • Be precise about the proposed outcome of the feature and how it relates to existing features. Include implementation details if possible.

🚧 Issue

You can triage issues which may include reproducing bug reports or asking for additional information, such as version numbers or reproduction instructions. Any help you can provide to quickly resolve an issue is very much appreciated!

🔁 Submitting Pull Requests

We love pull requests!Before forking the repo and creating a pull request for non-trivial changes, it is usually best to first open an issue to discuss the changes, or discuss your intended approach for solving the problem in the comments for an existing issue.

All contributions will be licensed under the project's license.

  • Small is better
  • Prioritize understanding over cleverness
  • Follow existing coding style and conventions
  • Include unit test
  • Add document
  • Resolve any merge conflicts
  • Promptly address any CI failures.

📝 Writing Commit Messages

Please read write a great commit message.

You can follow Angular Conventional Commits

✅ Code Review

Everyone can review other people's code. But please follow the rules:

  • Review the code, not the author. Look for and suggest improvements without disparaging or insulting the author. Provide actionable feedback and explain your reasoning.
  • You are not your code. When your code is critiqued, questioned, or constructively criticized, remember that you are not your code. Do not take code review personally.
  • Always do your best. No one writes bugs on purpose. Do your best, and learn from your mistakes.
  • Kindly note any violations to the guidelines specified in this document.