Contributing¶
This document provides guidelines for contributing to the Stratpoint Timesheet Application. Whether you're fixing bugs, adding features, or improving documentation, these guidelines will help ensure a smooth contribution process.
Getting Started¶
Prerequisites¶
Before contributing, ensure you have:
- PHP 8.1 or higher
- Node.js 18 or higher
- MySQL 8.0 or higher
- Redis 7.0 or higher
- Composer
- Git
Development Environment Setup¶
-
Clone the repository
-
Install dependencies
-
Environment configuration
-
Database setup
-
Build assets
-
Start development server
Contribution Workflow¶
Branch Strategy¶
We use Git Flow branching model:
graph LR
A[main] --> B[develop]
B --> C[feature/feature-name]
B --> D[bugfix/bug-description]
B --> E[hotfix/critical-fix]
C --> B
D --> B
E --> A
E --> B
Branch Naming Conventions¶
- Feature branches:
feature/JIRA-123-add-timesheet-approval - Bug fix branches:
bugfix/JIRA-456-fix-calculation-error - Hotfix branches:
hotfix/JIRA-789-security-patch - Release branches:
release/v2.1.0
Commit Message Format¶
Follow the Conventional Commits specification:
Types¶
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
- test: Adding missing tests or correcting existing tests
- chore: Changes to the build process or auxiliary tools
Examples¶
feat(timesheet): add bulk approval functionality
- Add bulk selection for timesheet entries
- Implement batch approval API endpoint
- Add confirmation dialog for bulk actions
Closes JIRA-123
fix(auth): resolve JWT token expiration issue
The JWT tokens were expiring too quickly due to incorrect
timezone calculation in the token generation logic.
Fixes JIRA-456
Code Contribution Guidelines¶
Code Quality Standards¶
- Follow PSR-12 coding standards for PHP
- Use ESLint configuration for JavaScript
- Maintain test coverage above 80%
- Write self-documenting code with clear variable and function names
- Add PHPDoc comments for all public methods
- Follow SOLID principles
Pull Request Process¶
-
Create feature branch from
develop -
Make your changes following coding standards
-
Write tests for new functionality
-
Update documentation if necessary
-
Commit changes with descriptive messages
-
Push to your branch
-
Create Pull Request with detailed description
Pull Request Template¶
## Description
Brief description of the changes made.
## Type of Change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Documentation update
## Related Issues
- Closes JIRA-123
- Related to JIRA-456
## Testing
- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] Manual testing completed
- [ ] Browser compatibility tested
## Screenshots (if applicable)
Add screenshots to help explain your changes.
## Checklist
- [ ] My code follows the style guidelines of this project
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes
Code Review Process¶
For Contributors¶
- Self-review your code before submitting
- Ensure all tests pass locally
- Update documentation as needed
- Respond promptly to review feedback
- Make requested changes in additional commits
For Reviewers¶
- Review within 24 hours of submission
- Check code quality and adherence to standards
- Verify test coverage and functionality
- Provide constructive feedback
- Approve or request changes with clear explanations
Review Checklist¶
- [ ] Code follows project coding standards
- [ ] All tests pass
- [ ] Test coverage is adequate
- [ ] Documentation is updated
- [ ] No security vulnerabilities introduced
- [ ] Performance impact considered
- [ ] Breaking changes documented
- [ ] Database migrations are reversible
- [ ] Error handling is appropriate
Testing Requirements¶
Required Tests¶
- Unit Tests for all new functions/methods
- Feature Tests for API endpoints
- Integration Tests for complex workflows
- Browser Tests for UI changes
Test Examples¶
Unit Test Example¶
/** @test */
public function it_calculates_overtime_hours_correctly()
{
// Arrange
$user = User::factory()->create();
$regularHours = 40;
$totalHours = 45;
// Act
$overtimeHours = $this->timesheetService->calculateOvertimeHours($user, $totalHours, $regularHours);
// Assert
$this->assertEquals(5, $overtimeHours);
}
Feature Test Example¶
/** @test */
public function authenticated_user_can_approve_timesheet()
{
// Arrange
$manager = User::factory()->create(['role' => 'manager']);
$timesheet = Timesheet::factory()->create(['approval_status' => 'pending']);
Sanctum::actingAs($manager);
// Act
$response = $this->putJson("/api/timesheets/{$timesheet->id}/approve");
// Assert
$response->assertStatus(200);
$this->assertDatabaseHas('timelogs', [
'id' => $timesheet->id,
'approval_status' => 'approved'
]);
}
Documentation Guidelines¶
Documentation Types¶
- Code Documentation: PHPDoc comments, inline comments
- API Documentation: OpenAPI/Swagger specifications
- User Documentation: Feature guides, tutorials
- Technical Documentation: Architecture, deployment guides
Documentation Standards¶
- Use clear, concise language
- Include code examples where appropriate
- Keep documentation up-to-date with code changes
- Use proper markdown formatting
- Include diagrams for complex concepts
Example Documentation¶
/**
* Calculate utilization rate for a user in a given period
*
* This method calculates the utilization rate by comparing actual hours
* worked against expected hours based on working days in the period.
*
* @param User $user The user to calculate utilization for
* @param Carbon $startDate Start of the calculation period
* @param Carbon $endDate End of the calculation period
* @return float Utilization rate as percentage (0-100)
* @throws TimesheetException When no working days in period
*
* @example
* $rate = $service->calculateUtilizationRate($user, $start, $end);
* // Returns: 85.5 (representing 85.5% utilization)
*/
public function calculateUtilizationRate(User $user, Carbon $startDate, Carbon $endDate): float
{
// Implementation...
}
Issue Reporting¶
Bug Reports¶
When reporting bugs, include:
- Clear description of the issue
- Steps to reproduce the problem
- Expected behavior
- Actual behavior
- Environment details (OS, browser, PHP version)
- Screenshots or logs if applicable
Bug Report Template¶
## Bug Description
A clear and concise description of what the bug is.
## Steps to Reproduce
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error
## Expected Behavior
A clear and concise description of what you expected to happen.
## Actual Behavior
A clear and concise description of what actually happened.
## Screenshots
If applicable, add screenshots to help explain your problem.
## Environment
- OS: [e.g. macOS 12.0]
- Browser: [e.g. Chrome 95.0]
- PHP Version: [e.g. 8.1.0]
- Laravel Version: [e.g. 8.75.0]
## Additional Context
Add any other context about the problem here.
Feature Requests¶
When requesting features, include:
- Problem statement - what problem does this solve?
- Proposed solution - how should it work?
- Alternative solutions - what other approaches were considered?
- Use cases - who would benefit from this feature?
- Priority level - how important is this feature?
Security Guidelines¶
Security Considerations¶
- Never commit sensitive data (passwords, API keys, etc.)
- Use environment variables for configuration
- Validate all input from users
- Sanitize output to prevent XSS
- Use parameterized queries to prevent SQL injection
- Follow OWASP guidelines
Reporting Security Issues¶
For security vulnerabilities:
- Do not create public issues
- Email security team directly: security@stratpoint.com
- Include detailed description and reproduction steps
- Allow time for fix before public disclosure
Community Guidelines¶
Code of Conduct¶
We are committed to providing a welcoming and inclusive environment:
- Be respectful and professional
- Be collaborative and helpful
- Be patient with newcomers
- Focus on constructive feedback
- Respect different viewpoints
Communication Channels¶
- Slack: #timesheet-dev channel
- Email: dev-team@stratpoint.com
- Jira: For issue tracking
- Confluence: For documentation
Recognition¶
Contributors will be recognized through:
- Contributor list in README
- Release notes acknowledgments
- Team meetings recognition
- Annual awards for significant contributions
Thank you for contributing to the Stratpoint Timesheet Application!