71 lines
3.1 KiB
Markdown
71 lines
3.1 KiB
Markdown
# Contributing
|
|
|
|
Before you start working on the codebase **make sure** you have signed the NDA provided by **Difuse**, if you haven't yet please contact Hayzam at [hayzam@difuse.io](mailto:hayzam@difuse.io).
|
|
|
|
Join the discord group [here](https://discord.gg/u6RupFDMp9) for general discussions.
|
|
|
|
## Contributing Rules for all projects related to Difuse
|
|
|
|
### 1. Code of Conduct
|
|
- Always maintain a professional and respectful tone in discussions.
|
|
- Any form of harassment, trolling, or abuse is strictly prohibited.
|
|
|
|
### 2. Setup and Environment
|
|
- Ensure you have the recommended development environment set up, including the correct versions of dependencies.
|
|
- Instructions for setting up the development environment should be documented in the project's README or a separate `CONTRIBUTING.md` file.
|
|
- We recommend using VSCode, Neovim or WebStorm (or GoLand) as your IDE/Editor.
|
|
- Test on a live device (apart from unit tests) before commiting to the repository.
|
|
|
|
### 3. Branching Strategy
|
|
- Use feature branches. Create a new branch for each feature or bugfix.
|
|
- Avoid committing directly to the `main` or `master` branch.
|
|
- Consider following a branching strategy like Git Flow or GitHub Flow.
|
|
|
|
### 4. Commit Messages
|
|
- Write clear and descriptive commit messages.
|
|
- Start with a short summary (50 chars or less), followed by a blank line and a detailed description if necessary.
|
|
- Consider following the conventional commit format: `<type>: <description>`
|
|
|
|
### 5. Testing
|
|
- Add tests for new features and ensure existing tests pass.
|
|
- Maintain or improve the current code coverage.
|
|
- Test across multiple browsers or environments if applicable.
|
|
|
|
### 6. Coding Standards
|
|
- Follow the project's coding standards and style guides.
|
|
- Document functions, methods, and classes.
|
|
- Ensure code is clear, maintainable, and well-organized.
|
|
|
|
### 7. Pull Requests (PRs)
|
|
- Make PRs small and focused. They should address a single issue or feature.
|
|
- Describe the changes in the PR description and reference any related issues.
|
|
- Ensure PRs pass all Continuous Integration (CI) checks.
|
|
- Request reviews from relevant team members.
|
|
- Address review feedback promptly.
|
|
|
|
### 8. Dependencies
|
|
- Regularly check and update project dependencies.
|
|
- When adding a new dependency, ensure it's necessary and doesn't add significant bloat to the project.
|
|
|
|
### 9. Documentation
|
|
- Update documentation in tandem with code changes.
|
|
- If adding a new feature, provide usage examples and relevant details.
|
|
|
|
### 10. Issue Reporting
|
|
- Check if an issue already exists before creating a new one.
|
|
- Provide clear details, steps to reproduce, and expected vs. actual behavior.
|
|
|
|
### 11. Performance
|
|
- Ensure that new features do not degrade the performance of the application.
|
|
- Regularly profile and optimize the codebase.
|
|
|
|
### 12. Accessibility
|
|
- Ensure the web application is accessible to all users, including those with disabilities.
|
|
- Follow WAI-ARIA guidelines and test with accessibility tools.
|
|
|
|
### 13. Responsiveness
|
|
- Ensure the application looks and functions well on various screen sizes and devices.
|
|
|
|
### 14. Feedback Loop
|
|
- Actively engage with the community and/or customers and address feedback, suggestions, and concerns.
|
|
|