Contributing Guidelines

​

Getting Started

1. Review the documentation
2. Search existing issues for similar problems or suggestions
3. Set up your development environment
4. Familiarize yourself with the codebase structure

​

Ways to Contribute

• Bug reports - Report issues you encounter
• Feature suggestions - Propose new functionality
• Code contributions - Submit bug fixes or new features
• Documentation - Improve guides and references
• Testing - Validate releases and report results
• Community support - Help other users

​

Legal Notice

​

Reporting Bugs

​

Before Submitting a Bug Report

1. Use the latest version - Verify the bug exists in the most recent release
2. Check documentation - Ensure it’s not a configuration issue
3. Search existing issues - Check if the bug is already reported in the issue tracker
4. Collect information:
   • Stack trace or error messages
   • Operating system and version
   • Node.js, npm, and yarn versions
   • Plugin version and OpenSearch Dashboards version
   • Steps to reproduce
   • Expected vs actual behavior

​

Submitting a Bug Report

• Clear title - Briefly describe the issue
• Reproduction steps - Detailed steps to reproduce the bug
• Expected behavior - What should happen
• Actual behavior - What actually happens
• Environment details - OS, versions, configuration
• Additional context - Screenshots, logs, code samples

​

After Submission

1. Label the issue appropriately
2. Attempt to reproduce the issue
3. Request additional information if needed (labeled needs-repro)
4. Mark as needs-fix if reproducible
5. Assign to a milestone for implementation

​

Suggesting Enhancements

​

Before Submitting an Enhancement

1. Use the latest version - Feature may already exist
2. Read documentation - Functionality might be available through configuration
3. Search existing issues - Enhancement may already be suggested
4. Consider scope - Ensure feature benefits majority of users

​

Submitting an Enhancement Suggestion

• Clear title - Describe the enhancement concisely
• Detailed description - Step-by-step explanation of the proposed feature
• Current behavior - What exists today
• Proposed behavior - What should exist and why
• Use cases - Real-world scenarios where this helps
• Alternatives considered - Other approaches you evaluated
• Additional context - Mockups, diagrams, examples from other projects

​

Code Contributions

​

Development Workflow

1. Fork the repository on GitHub
2. Clone your fork locally:

git clone https://github.com/YOUR-USERNAME/wazuh-dashboard-plugins.git
cd wazuh-dashboard-plugins

3. Create a feature branch:

git checkout -b feature/my-enhancement

4. Set up development environment (see Setup Guide)
5. Make your changes:
   • Write code following the Style Guide
   • Add tests for new functionality
   • Update documentation as needed
6. Test your changes:

cd plugins/main
yarn test:jest
yarn lint

7. Commit your changes (see Commit Guidelines)
8. Push to your fork:

git push origin feature/my-enhancement

9. Open a pull request on GitHub

​

Docker Development Environments

• OpenSearch indexer
• Wazuh manager
• OpenSearch Dashboards development environment
• Optional Wazuh agents
• Supporting services (Imposter mock server, metrics exporters)

​

Style Guide

​

Key Style Rules

​

Code Formatting

• Indentation: 2 spaces (never tabs)
• Line length: 100 characters maximum
• Newlines: UNIX-style (\n)
• Semicolons: Always use semicolons
• Quotes: Single quotes for strings (unless interpolating)
• Template literals: Use for string interpolation and multi-line strings

​

Variables

// Good
const maxWidth = 300;
const userName = 'admin';

// Bad
var maxWidth = 300;
let userName = "admin";

• Use const by default
• Use let only when reassignment is necessary
• Never use var

​

Functions

// Good - function declaration
function getUserName(user) {
  return user.name;
}

// Good - arrow function for callbacks
users.map(user => user.name);

// Bad - function expression
const getUserName = function(user) {
  return user.name;
};

​

Naming Conventions

• Variables/functions: lowerCamelCase
• Classes: UpperCamelCase
• Constants: lowerCamelCase (not UPPER_CASE)
• Private methods: Prefix with underscore _privateMethod

​

Destructuring

// Good
const { firstName, lastName } = user;

// Bad
const firstName = user.firstName;
const lastName = user.lastName;

​

Modern JavaScript

• Use ES2015+ features (arrow functions, destructuring, spread operator)
• Avoid for loops - use .map(), .filter(), .reduce()
• Use async/await over Promise chains
• Use object/array spread over Object.assign() or .slice()

​

Code Quality Tools

• ESLint - JavaScript/TypeScript linting
• Prettier - Code formatting
• TypeScript - Type checking

yarn lint          # Check for linting errors
yarn lint:fix      # Auto-fix linting errors
yarn format        # Format code with Prettier

​

Commit Messages

​

Format

<Type>: <Subject>

<Body>

<Footer>

​

Rules

1. Separate subject from body with a blank line
2. Limit subject line to 50 characters
3. Capitalize the subject line
4. No period at end of subject line
5. Use imperative mood - “Add feature” not “Added feature”
6. Wrap body at 72 characters
7. Sign commits when possible

​

Examples

Add user authentication module

Implement JWT-based authentication for API endpoints.
Includes login, logout, and token refresh functionality.

Resolves: #123

Fix memory leak in dashboard component

Remove event listeners in componentWillUnmount to prevent
memory leaks when components are destroyed.

Fixes: #456

​

Commit Types

• Add: New feature or functionality
• Update: Enhancement to existing feature
• Fix: Bug fix
• Refactor: Code restructuring without behavior change
• Test: Adding or updating tests
• Docs: Documentation changes
• Style: Code style changes (formatting, etc.)
• Chore: Maintenance tasks (dependencies, build, etc.)

​

Pull Request Process

​

Before Opening a Pull Request

• Code follows the style guide
• Tests pass: yarn test:jest
• Linting passes: yarn lint
• Commits follow commit guidelines
• Branch is up to date with base branch
• Documentation is updated if needed

​

Pull Request Template

## Description
Brief description of changes

## Related Issue
Fixes #123

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Enhancement
- [ ] Documentation update

## Testing
Describe testing performed

## Screenshots (if applicable)
Add screenshots for UI changes

## Checklist
- [ ] Tests pass
- [ ] Linting passes
- [ ] Documentation updated

​

Review Process

1. Automated checks run (CI/CD pipeline)
2. Code review by maintainers
3. Feedback provided through PR comments
4. Revisions made based on feedback
5. Approval by required reviewers
6. Merge by maintainers

​

Testing Contributions

• Unit tests for new functions and components
• Integration tests for component interactions
• Snapshot updates for UI changes

​

Documentation Contributions

• Fix typos and grammatical errors
• Clarify confusing sections
• Add examples and use cases
• Improve code comments
• Update outdated information

• README.md - Project overview
• CONTRIBUTING.md - This guide
• STYLEGUIDE.md - Code style reference
• docs/ - Detailed documentation

​

Community Guidelines

​

Be Respectful

• Use welcoming and inclusive language
• Respect differing viewpoints and experiences
• Accept constructive criticism gracefully
• Focus on what’s best for the community

​

Get Help

• Join the Slack community
• Ask questions in GitHub Discussions
• Review existing documentation

​

Recognition

• Listed in release notes for their contributions
• Mentioned in the project’s contributor list
• Acknowledged in relevant issue/PR discussions

​

Additional Resources

• Project Website
• Documentation
• Installation Guide
• Branches and Tags
• Security Policy

​

License