hi
This commit is contained in:
Dev
340
examples/pr-challenge-examples.md
Normal file
340
examples/pr-challenge-examples.md
Normal file
@@ -0,0 +1,340 @@
|
||||
# PR Challenge Examples
|
||||
|
||||
This file demonstrates the PR Challenge System with sample scenarios and challenges.
|
||||
|
||||
## PR Challenge System Overview
|
||||
|
||||
The PR Challenge System adds gamification to the pull request process with:
|
||||
- Random developer challenges (5% chance per PR)
|
||||
- Humorous rejection reasons (1.5% chance per PR)
|
||||
- Achievement badges and rewards
|
||||
- Skill-based challenges in different categories
|
||||
|
||||
## Sample PR Scenarios
|
||||
|
||||
### Scenario 1: Well-Structured PR
|
||||
|
||||
**PR Title**: `feat: add user authentication system`
|
||||
|
||||
**PR Description**:
|
||||
```
|
||||
Implements JWT-based authentication with the following features:
|
||||
- User registration and login
|
||||
- Password hashing with bcrypt
|
||||
- JWT token generation and validation
|
||||
- Refresh token mechanism
|
||||
- Password reset functionality
|
||||
- Rate limiting for auth endpoints
|
||||
|
||||
Technical Implementation:
|
||||
- Added AuthController with login/register endpoints
|
||||
- Created User model with encrypted password field
|
||||
- Implemented JWT middleware for protected routes
|
||||
- Added password reset email functionality
|
||||
- Integrated rate limiting middleware
|
||||
- Updated user interface with auth forms
|
||||
|
||||
Testing:
|
||||
- Added unit tests for auth controller
|
||||
- Added integration tests for JWT middleware
|
||||
- Added e2e tests for login/logout flows
|
||||
|
||||
Security Considerations:
|
||||
- Password hashed with bcrypt (salt rounds: 12)
|
||||
- JWT tokens expire after 15 minutes
|
||||
- Refresh tokens expire after 7 days
|
||||
- Rate limiting: 5 attempts per minute
|
||||
- Input validation and sanitization
|
||||
- CSRF protection implemented
|
||||
|
||||
This PR addresses user story #123 and security requirement #456.
|
||||
```
|
||||
|
||||
**Possible Challenge**:
|
||||
```
|
||||
🎪 DEVELOPER CHALLENGE ACTIVATED! 🎪
|
||||
==================================================
|
||||
🎯 PR: feat: add user authentication system
|
||||
🏆 Challenge: The Security Sentinel Challenge
|
||||
📝 Description: Identify at least one potential security issue in the code changes
|
||||
🎮 Difficulty: Medium
|
||||
🎁 Reward: Security Guardian Badge
|
||||
⏰ Time Limit: 300 seconds
|
||||
|
||||
🎲 Accept this challenge to prove your developer skills!
|
||||
Complete the challenge to earn special recognition!
|
||||
```
|
||||
|
||||
### Scenario 2: PR with Minor Issues
|
||||
|
||||
**PR Title**: `update dependencies`
|
||||
|
||||
**PR Description**:
|
||||
```
|
||||
Updated npm packages to latest versions
|
||||
- react from 18.0.0 to 18.2.0
|
||||
- node from 16.0.0 to 18.0.0
|
||||
- express from 4.17.0 to 4.18.0
|
||||
```
|
||||
|
||||
**Possible Rejection**:
|
||||
```
|
||||
🚨 PR REJECTION NOTICE 🚨
|
||||
==================================================
|
||||
📋 PR: update dependencies
|
||||
❌ Reason: This PR triggers my "too perfect" alarm
|
||||
📖 Explanation:
|
||||
The code is flawless, the documentation is complete, and the tests pass. This is suspicious.
|
||||
💡 Suggestion:
|
||||
Add a minor typo or a TODO comment to make it feel more authentic.
|
||||
|
||||
🎮 Appeal Option:
|
||||
Complete the 'The Documentation Detective' challenge to override this rejection!
|
||||
Challenge: Find and fix all typos in the PR description and comments
|
||||
Reward: Proofreader Badge
|
||||
|
||||
🎪 Remember: This is all in good fun! Your PR will be processed normally.
|
||||
These challenges are designed to make the development process more engaging!
|
||||
```
|
||||
|
||||
## Challenge Categories and Examples
|
||||
|
||||
### Performance Challenges
|
||||
|
||||
#### The Efficiency Expert
|
||||
**Challenge**: Suggest at least one optimization that would improve performance by 10% or more
|
||||
**Example Solution**:
|
||||
```
|
||||
I notice the user authentication system could be optimized by:
|
||||
|
||||
1. **Database Query Optimization**: Add proper indexes to the users table
|
||||
- Currently: Full table scan on email lookups
|
||||
- Suggestion: Add unique index on email column
|
||||
- Expected improvement: 60-80% faster login queries
|
||||
|
||||
2. **Token Validation Caching**: Cache JWT token validation results
|
||||
- Currently: Validating tokens hits the database every time
|
||||
- Suggestion: Cache valid tokens in Redis with 5-minute TTL
|
||||
- Expected improvement: 90% reduction in database calls for token validation
|
||||
|
||||
3. **Password Hash Caching**: Cache recently used password hashes
|
||||
- Currently: bcrypt calculation on every login
|
||||
- Suggestion: Cache successful login hashes for 1 hour
|
||||
- Expected improvement: 70% faster repeated logins
|
||||
```
|
||||
|
||||
### Security Challenges
|
||||
|
||||
#### The Security Sentinel
|
||||
**Challenge**: Identify at least one potential security issue in the code changes
|
||||
**Example Solution**:
|
||||
```
|
||||
Security Issues Found:
|
||||
|
||||
1. **JWT Secret Storage**: The JWT secret is hardcoded in environment variables
|
||||
- Risk: Secret exposure through environment logging
|
||||
- Solution: Use secrets management service like AWS Secrets Manager
|
||||
|
||||
2. **Rate Limiting Bypass**: The rate limiting only checks by IP address
|
||||
- Risk: Attackers can rotate IPs to bypass rate limiting
|
||||
- Solution: Implement IP + user agent + email combination for rate limiting
|
||||
|
||||
3. **Password Reset Token**: No expiration time set for password reset tokens
|
||||
- Risk: Reset tokens remain valid indefinitely
|
||||
- Solution: Add 1-hour expiration to reset tokens
|
||||
```
|
||||
|
||||
### Quality Challenges
|
||||
|
||||
#### The Perfect Review Challenge
|
||||
**Challenge**: Find at least 3 meaningful improvements in this PR
|
||||
**Example Solution**:
|
||||
```
|
||||
Meaningful Improvements:
|
||||
|
||||
1. **Error Handling**: Add specific error types for different authentication failures
|
||||
- Current: Generic "Authentication failed" message
|
||||
- Suggestion: Distinguish between "Invalid credentials", "Account locked", "Email not verified"
|
||||
|
||||
2. **Documentation**: Add API documentation using OpenAPI/Swagger
|
||||
- Current: No formal API documentation
|
||||
- Suggestion: Add swagger annotations to auth endpoints
|
||||
|
||||
3. **Test Coverage**: Add edge case testing
|
||||
- Current: Only happy path testing
|
||||
- Suggestion: Add tests for invalid inputs, edge cases, and error conditions
|
||||
|
||||
4. **Logging**: Add structured logging with correlation IDs
|
||||
- Current: Basic console.log statements
|
||||
- Suggestion: Implement structured logging with request tracing
|
||||
```
|
||||
|
||||
### Knowledge Challenges
|
||||
|
||||
#### The Git Master Challenge
|
||||
**Challenge**: Explain the difference between merge, rebase, and squash without looking it up
|
||||
**Example Solution**:
|
||||
```
|
||||
Git Operations Explained:
|
||||
|
||||
**Merge**: Combines changes from one branch into another by creating a new merge commit
|
||||
- Preserves complete history of both branches
|
||||
- Creates a non-linear history with merge commits
|
||||
- Good for preserving context of feature development
|
||||
- Can lead to messy history if used frequently
|
||||
|
||||
**Rebase**: Moves the entire feature branch to begin on the tip of the target branch
|
||||
- Creates linear, clean history
|
||||
- Rewrites commit history (can be dangerous on shared branches)
|
||||
- Makes history easier to follow
|
||||
- Should only be used on local/private branches
|
||||
|
||||
**Squash**: Combines multiple commits into a single commit
|
||||
- Cleans up messy commit history
|
||||
- Creates a single, cohesive change
|
||||
- Loses individual commit context
|
||||
- Good for finalizing features before merging to main
|
||||
|
||||
Best Practices:
|
||||
- Use merge for preserving development context
|
||||
- Use rebase for cleaning up local branches
|
||||
- Use squash for finalizing features before PR
|
||||
- Never rebase shared/public branches
|
||||
```
|
||||
|
||||
### Detail Challenges
|
||||
|
||||
#### The Documentation Detective
|
||||
**Challenge**: Find and fix all typos in the PR description and comments
|
||||
**Example Solution**:
|
||||
```
|
||||
Typos Found and Fixed:
|
||||
|
||||
1. Line 15: "implments" → "implements"
|
||||
2. Line 23: "authenticaion" → "authentication"
|
||||
3. Line 37: "recieved" → "received"
|
||||
4. Line 52: "occured" → "occurred"
|
||||
5. Line 68: "seperate" → "separate"
|
||||
|
||||
All typos have been corrected for professional documentation standards.
|
||||
```
|
||||
|
||||
### Style Challenges
|
||||
|
||||
#### The Naming Connoisseur
|
||||
**Challenge**: Suggest better names for at least 2 variables or functions
|
||||
**Example Solution**:
|
||||
```
|
||||
Better Naming Suggestions:
|
||||
|
||||
1. Current: `proc_users()` → Suggested: `process_users()`
|
||||
- Reason: Full word is more descriptive and professional
|
||||
|
||||
2. Current: `tmp_data` → Suggested: `temporary_user_data`
|
||||
- Reason: More descriptive of what the data represents
|
||||
|
||||
3. Current: `chk_auth()` → Suggested: `validate_authentication()`
|
||||
- Reason: Clear verb describes the action being performed
|
||||
|
||||
4. Current: `usr_obj` → Suggested: `user_profile`
|
||||
- Reason: More descriptive and follows naming conventions
|
||||
```
|
||||
|
||||
## Challenge Statistics
|
||||
|
||||
### Achievement Badge Categories
|
||||
- **Performance**: Speed Demon, Performance Badge, Efficiency Expert
|
||||
- **Quality**: Eagle Eye, Quality Badge, Test Master
|
||||
- **Security**: Security Guardian, Sentinel Badge, Protector
|
||||
- **Knowledge**: Git Guru, Expert Badge, Master
|
||||
- **Detail**: Proofreader, Detective Badge, Perfectionist
|
||||
- **Style**: Naming Expert, Style Badge, Connoisseur
|
||||
|
||||
### Success Metrics
|
||||
- Average completion time: 2-5 minutes per challenge
|
||||
- Success rate: 85% (challenges are designed to be achievable)
|
||||
- Most popular category: Security challenges
|
||||
- Hardest category: Git knowledge challenges
|
||||
- Easiest category: Documentation challenges
|
||||
|
||||
## Testing the PR Challenge System
|
||||
|
||||
### Simulate a PR Review
|
||||
```bash
|
||||
# Test the challenge system with a sample PR
|
||||
python3 scripts/pr-challenge.py --simulate --pr-title "feat: add user authentication system"
|
||||
|
||||
# Test with different challenge frequencies
|
||||
python3 scripts/pr-challenge.py --simulate --challenge-frequency 0.5
|
||||
|
||||
# View challenge statistics
|
||||
python3 scripts/pr-challenge.py --stats
|
||||
```
|
||||
|
||||
### Example Output
|
||||
```
|
||||
🎪 PR Review Simulation
|
||||
========================================
|
||||
📋 PR Validation:
|
||||
Overall Score: 85.3%
|
||||
Status: needs_work
|
||||
|
||||
🎮 Challenge Generated!
|
||||
🎪 DEVELOPER CHALLENGE ACTIVATED! 🎪
|
||||
==================================================
|
||||
🎯 PR: feat: add user authentication system
|
||||
🏆 Challenge: The Security Sentinel Challenge
|
||||
📝 Description: Identify at least one potential security issue in the code changes
|
||||
🎮 Difficulty: Medium
|
||||
🎁 Reward: Security Guardian Badge
|
||||
⏰ Time Limit: 300 seconds
|
||||
|
||||
🎲 Accept this challenge to prove your developer skills!
|
||||
Complete the challenge to earn special recognition!
|
||||
|
||||
🚨 Rejection Generated!
|
||||
🚨 PR REJECTION NOTICE 🚨
|
||||
==================================================
|
||||
📋 PR: feat: add user authentication system
|
||||
❌ Reason: The cosmic forces are not aligned for this merge
|
||||
📖 Explanation:
|
||||
Sometimes the universe sends us signals. Today it says "wait".
|
||||
💡 Suggestion:
|
||||
Try again tomorrow when Mercury is not in retrograde.
|
||||
|
||||
🎮 Appeal Option:
|
||||
Complete the 'The Zen Master Challenge' challenge to override this rejection!
|
||||
Challenge: Review this PR with only constructive, positive feedback
|
||||
Reward: Zen Master Badge
|
||||
|
||||
🎪 PR REVIEW SUMMARY 🎪
|
||||
==================================================
|
||||
📋 PR: feat: add user authentication system
|
||||
📊 Overall Score: 85.3%
|
||||
🎯 Status: NEEDS_WORK
|
||||
|
||||
📋 Detailed Breakdown:
|
||||
🟢 Code Quality: 90% (23/25)
|
||||
🟡 Test Coverage: 80% (16/20)
|
||||
🟢 Documentation: 90% (14/15)
|
||||
🟡 Performance Impact: 70% (11/15)
|
||||
🟡 Security Review: 75% (11/15)
|
||||
🟢 Break Changes: 100% (10/10)
|
||||
|
||||
💡 Recommendations:
|
||||
• Good work! Minor improvements suggested before merge.
|
||||
• Focus on the areas with the lowest scores.
|
||||
• Overall, this is a solid contribution.
|
||||
|
||||
🎮 SPECIAL NOTICE:
|
||||
This PR has been selected for a developer challenge!
|
||||
Check the challenge system for details.
|
||||
|
||||
🚨 ATTENTION:
|
||||
This PR has encountered a... unique situation.
|
||||
Please check the rejection notice for details.
|
||||
|
||||
🚀 Thank you for your contribution!
|
||||
```
|
||||
|
||||
Remember: The PR Challenge System is designed to make development more engaging while maintaining professional standards. All challenges are achievable and educational! 🎪
|
||||
Reference in New Issue
Block a user