Contributing to Zayed Shield
Thank you for your interest in contributing to Zayed Shield. This document provides guidelines for contributing to this project.
Table of Contents
- Code of Conduct
- Getting Started
- How to Contribute
- Development Process
- Pull Request Guidelines
- Coding Standards
- Testing Requirements
- Documentation
- Community
Code of Conduct
"The best way to find yourself is to lose yourself in the service of others." — Mahatma Gandhi
We are committed to fostering an inclusive and respectful community. All contributors are expected to:
- Treat everyone with respect and kindness
- Welcome diverse perspectives and experiences
- Accept constructive criticism gracefully
- Focus on what is best for the community
- Show empathy towards other community members
By participating in this project, you agree to abide by these principles.
Getting Started
Prerequisites
Before contributing, ensure you have:
- Git installed on your system
- A GitHub account
- Basic understanding of the project's technology stack
- Familiarity with our Security Policy
Setting Up Your Development Environment
# Fork the repository on GitHub
# Clone your fork
git clone https://github.com/YOUR-USERNAME/Zayed-Shield.git
# Navigate to the project directory
cd Zayed-Shield
# Add the original repository as upstream
git remote add upstream https://github.com/asrar-mared/Zayed-Shield.git
# Install dependencies
./scripts/setup.sh
How to Contribute
Ways to Contribute
We welcome contributions in many forms:
Code Contributions
- Bug fixes
- New features
- Performance improvements
- Code refactoring
Non-Code Contributions
- Documentation improvements
- Bug reports
- Feature suggestions
- Testing and quality assurance
- Translations
- Community support
Finding Issues to Work On
- Browse our issue tracker
- Look for issues labeled
good first issueorhelp wanted - Check our project roadmap
Development Process
Creating a Branch
Always create a new branch for your work:
# Update your local main branch
git checkout main
git pull upstream main
# Create a new branch
git checkout -b feature/your-feature-name
Branch Naming Convention:
-
feature/- New features -
fix/- Bug fixes -
docs/- Documentation changes -
refactor/- Code refactoring -
test/- Test improvements
Making Changes
- Make your changes in logical commits
- Write clear, descriptive commit messages
- Test your changes thoroughly
- Update documentation as needed
Commit Message Guidelines
We follow the Conventional Commits specification:
type(scope): brief description
Detailed explanation of the change (optional)
Fixes #123
Types:
-
feat- A new feature -
fix- A bug fix -
docs- Documentation changes -
style- Code style changes (formatting, etc.) -
refactor- Code refactoring -
test- Adding or updating tests -
chore- Maintenance tasks
Example:
feat(security): add enhanced encryption module
Implements AES-256 encryption for sensitive data storage.
This improves overall security posture of the application.
Fixes #456
Pull Request Guidelines
Before Submitting
- [ ] Code follows project style guidelines
- [ ] All tests pass locally
- [ ] New tests added for new functionality
- [ ] Documentation updated
- [ ] Commits are clean and well-organized
- [ ] Branch is up to date with main
Submitting Your Pull Request
- Push your branch to your fork:
git push origin feature/your-feature-name
Navigate to the repository
Click "New Pull Request"
Fill out the PR template completely
Request review from maintainers
Pull Request Template
## Description
[Clear description of what this PR does]
## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
## Testing
[Describe the testing you've performed]
## Checklist
- [ ] Code follows style guidelines
- [ ] Self-review completed
- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] No new warnings introduced
## Related Issues
Fixes #(issue number)
Review Process
- Maintainers will review your PR
- Feedback will be provided constructively
- Make requested changes if needed
- Once approved, a maintainer will merge
Average review time: 2-5 business days
Coding Standards
General Principles
"Quality is not an act, it is a habit." — Aristotle
- Write clean, readable code
- Follow language-specific best practices
- Keep functions small and focused
- Use meaningful variable names
- Comment complex logic
- Handle errors appropriately
Style Guidelines
Python
# Follow PEP 8
# Use type hints
def calculate_hash(data: str) -> str:
"""
Calculate SHA-256 hash of input data.
Args:
data: Input string to hash
Returns:
Hexadecimal hash string
"""
return hashlib.sha256(data.encode()).hexdigest()
JavaScript
// Use modern ES6+ syntax
// Follow Airbnb style guide
const processData = async (data) => {
try {
const result = await validateData(data);
return result;
} catch (error) {
logger.error('Data processing failed', error);
throw error;
}
};
Shell Scripts
#!/bin/bash
# Use descriptive variable names
# Add error handling
set -euo pipefail
readonly SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
Testing Requirements
Test Coverage
We maintain high standards for code quality:
- Unit tests for all new functions
- Integration tests for features
- Minimum 80% code coverage
- All tests must pass before merge
Running Tests
# Run all tests
make test
# Run specific test suite
pytest tests/unit/
# Run with coverage
pytest --cov=src tests/
# Run linting
make lint
Writing Tests
import pytest
def test_hash_calculation():
"""Test hash calculation produces expected output."""
input_data = "test string"
expected = "d5579c46dfcc7f18207013e65b44e4cb4e2c2298f4ac457ba8f82743f31e930b"
result = calculate_hash(input_data)
assert result == expected
Documentation
"Documentation is a love letter that you write to your future self." — Damian Conway
What to Document
- New features and APIs
- Configuration options
- Installation procedures
- Usage examples
- Troubleshooting guides
Documentation Standards
- Use clear, concise language
- Include code examples
- Keep documentation up to date
- Use proper markdown formatting
Example Documentation
## Function: validateInput
Validates user input against security requirements.
### Parameters
- `input` (string): The input string to validate
- `options` (object): Validation options
- `maxLength` (number): Maximum allowed length
- `allowSpecialChars` (boolean): Allow special characters
### Returns
`boolean`: True if validation passes, false otherwise
### Example
\`\`\`javascript
const isValid = validateInput(userInput, {
maxLength: 100,
allowSpecialChars: false
});
\`\`\`
### Throws
- `ValidationError`: If input format is invalid
Community
Communication Channels
- GitHub Issues - Bug reports and feature requests
- GitHub Discussions - General questions and discussions
- Pull Requests - Code review and collaboration
Getting Help
If you need assistance:
- Check existing documentation
- Search closed issues
- Ask in GitHub Discussions
- Open a new issue with details
Recognition
We value all contributions and recognize contributors in:
- Release notes
- Project README
- Annual contributor highlights
Thank You
"Alone we can do so little; together we can do so much." — Helen Keller
Your contributions make this project better for everyone. We appreciate your time and effort in helping improve Zayed Shield.
Happy Contributing! 🚀
Additional Resources
Zayed Shield - Built with dedication by contributors worldwide
Made with ❤️ in UAE 🇦🇪
Top comments (0)