graph TD
    A[Original Repository<br/>upstream] -->|Fork| B[Your Fork<br/>origin]
    B -->|Clone| C[Local Repository]
    C -->|Push| B
    B -->|Pull Request| A
    A -->|Sync| B

# 1. Fork the repository via GitHub UI
# Navigate to: https://github.com/ORGANIZATION/project-name
# Click "Fork" → Select your account

# 2. Clone with proper configuration
git clone git@github.com:YOUR_USERNAME/project-name.git
cd project-name

# 3. Configure remotes for synchronization
git remote add upstream git@github.com:ORGANIZATION/project-name.git
git remote set-url --push upstream DISABLE  # Prevent accidental pushes

# 4. Verify remote configuration
git remote -v
# Expected output:
# origin    git@github.com:YOUR_USERNAME/project-name.git (fetch)
# origin    git@github.com:YOUR_USERNAME/project-name.git (push)
# upstream  git@github.com:ORGANIZATION/project-name.git (fetch)
# upstream  DISABLE (push)

# 5. Set up branch tracking
git fetch upstream
git branch --set-upstream-to=upstream/main main

# 1. Sync with upstream before starting
git checkout main
git pull upstream main
git push origin main

# 2. Create feature branch with proper naming
git checkout -b feature/DOC-789-add-team-member

# 3. Make atomic, focused changes
echo "# Team Member: YOUR_NAME

## Professional Summary
Senior Software Engineer with 5+ years experience in full-stack development.
Specializing in microservices architecture and cloud-native applications.

## Technical Expertise
- **Languages:** JavaScript, Python, Go
- **Frameworks:** React, Node.js, Django
- **Cloud:** AWS, GCP, Kubernetes
- **Databases:** PostgreSQL, MongoDB, Redis

## Current Focus
- Implementing CI/CD pipelines
- Optimizing application performance
- Mentoring junior developers

## Contact
- Email: your.name@company.com
- GitHub: github.com/yourhandle
- LinkedIn: linkedin.com/in/yourname
" > team/YOUR_NAME.md

# 4. Stage and commit with conventional commit message
git add team/YOUR_NAME.md
git commit -m "feat(team): add YOUR_NAME to team directory

- Add professional profile with technical expertise
- Include contact information for collaboration
- Follow team documentation standards

Relates to: DOC-789"

# 5. Push to your fork
git push origin feature/DOC-789-add-team-member

## Summary
Brief description of changes and their purpose.

## 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
- [ ] Performance improvement
- [ ] Code refactoring

## Implementation Details
Detailed explanation of the technical implementation, architectural decisions, and approach taken.

## Testing
- [ ] Unit tests pass locally
- [ ] Integration tests completed
- [ ] Manual testing performed
- [ ] Performance impact assessed

### Test Coverage
- Current coverage: X%
- New coverage: Y%

## Checklist
- [ ] My code follows the project's style guidelines
- [ ] 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
- [ ] Any dependent changes have been merged and published

## Related Issues
Closes #789
Relates to #790, #791

## Screenshots (if applicable)
[Add relevant screenshots or recordings]

## Performance Impact
- [ ] No performance impact
- [ ] Performance improved
- [ ] Performance degraded (justified because...)

## Security Considerations
- [ ] No security impact
- [ ] Security review required
- [ ] Follows OWASP guidelines

## Deployment Notes
Special considerations for deployment, feature flags, or migration steps.

## Architecture & Design
- [ ] Follows established design patterns
- [ ] Maintains separation of concerns
- [ ] Avoids code duplication (DRY principle)
- [ ] Implements proper abstraction levels

## Code Quality
- [ ] Clear variable and function names
- [ ] Appropriate comments for complex logic
- [ ] Consistent code style
- [ ] No commented-out code

## Performance
- [ ] Efficient algorithms used
- [ ] No unnecessary database queries
- [ ] Proper caching implemented
- [ ] Resource cleanup handled

## Security
- [ ] Input validation present
- [ ] No hardcoded credentials
- [ ] SQL injection prevention
- [ ] XSS protection implemented

## Testing
- [ ] Unit tests included
- [ ] Edge cases covered
- [ ] Test coverage adequate
- [ ] Tests are maintainable

// ❌ Poor review comment:
"This is wrong. Fix it."

// ✅ Professional review comment:
"Consider using `Array.prototype.map()` here instead of a for loop. 
It would make the code more functional and easier to read:"

const processedData = rawData.map(item => ({
  id: item.id,
  name: item.name.trim(),
  timestamp: new Date(item.created_at)
}));

### Code Review Communication Standards

#### Constructive Feedback Template

// Suggested implementation

> **💡 💡 Pro Tip**
> Always review your own code first before requesting reviews. Use GitHub's self-review feature to add explanatory comments on complex sections.

### Common Code Review Anti-patterns to Avoid

| Anti-pattern | Why It's Problematic | Better Approach |
|--------------|---------------------|-----------------|
| Nitpicking | Focuses on style over substance | Use automated linters |
| Design changes in review | Too late in the process | Discuss design before implementation |
| Approval without reading | Defeats the purpose | Always review thoroughly |
| Personal attacks | Damages team morale | Focus on code, not person |
| Ignoring positive aspects | Discourages contributors | Balance criticism with praise |

## Part 4: Managing Review Feedback Professionally

### Responding to Code Review Comments

#### Professional Response Patterns

### Exercise 4: Implementing Review Feedback

### Keeping Your Fork Synchronized

#### Automated Sync Strategy

```bash
# Create a sync script for regular updates
cat > sync-fork.sh << 'EOF'
#!/bin/bash
set -e

echo "🔄 Syncing fork with upstream..."

# Stash any local changes
git stash push -m "Auto-stash before sync"

# Update main branch
git checkout main
git fetch upstream
git merge upstream/main --ff-only
git push origin main

# Return to previous branch
git checkout -

# Pop stash if exists
if git stash list | grep -q "Auto-stash before sync"; then
    git stash pop
fi

echo "✅ Fork synchronized successfully!"
EOF

chmod +x sync-fork.sh

---
name: Bug Report
about: Create a report to help us improve
title: '[BUG] '
labels: 'bug, needs-triage'
assignees: ''
---

## Bug Description
A clear and concise description of the bug.

## To Reproduce
Steps to reproduce the behavior:
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

## Expected Behavior
What you expected to happen.

## Actual Behavior
What actually happened.

## Environment
- OS: [e.g. macOS 12.1]
- Browser: [e.g. Chrome 96]
- Version: [e.g. 2.1.0]

## Additional Context
Any other context about the problem.

## Possible Solution
If you have suggestions on a fix.

# Use GitHub CLI for efficient issue management
gh issue create --title "Implement user authentication" \
  --body "## Description
We need to implement JWT-based authentication for the API.

## Acceptance Criteria
- [ ] User can register with email/password
- [ ] User can login and receive JWT token
- [ ] Protected routes require valid JWT
- [ ] Token refresh mechanism implemented

## Technical Requirements
- Use bcrypt for password hashing
- Implement rate limiting on auth endpoints
- Add comprehensive test coverage

## References
- [JWT Best Practices](https://tools.ietf.org/html/rfc8725)
- [OWASP Authentication Guide](https://owasp.org/)" \
  --label "feature,backend,priority-high" \
  --milestone "v2.0.0"

Columns:
  - Backlog (automation: to-do)
  - Ready for Dev (manual)
  - In Progress (automation: in-progress)
  - In Review (linked to PRs)
  - QA Testing (manual)
  - Done (automation: closed)

Automations:
  - When issue created → Add to Backlog
  - When PR opened → Move to In Review
  - When issue closed → Move to Done
  - When PR merged → Close linked issues

# 1. Create and link issues to project
gh issue create --title "API endpoint for user profile" \
  --project "Sprint 23" \
  --label "backend"

# 2. Convert issue to task with time estimate
gh issue edit 123 --add-label "effort/3-days"

# 3. Create PR linked to issue
git checkout -b feature/USER-123-profile-endpoint
# ... make changes ...
git commit -m "feat(api): add user profile endpoint

Implements GET/PUT /api/users/:id/profile

Closes #123"

# 4. Track progress in project board
gh issue comment 123 --body "Started implementation. Estimated completion: 2 days."

## Healthy Project Indicators
- [ ] Active maintainers (recent commits)
- [ ] Clear contribution guidelines
- [ ] Responsive to issues/PRs
- [ ] Well-documented codebase
- [ ] Automated testing
- [ ] Code of conduct
- [ ] License clarity

# Find issues in popular projects needing help
gh search issues "help wanted" \
  --language=javascript \
  --stars=">1000" \
  --updated=">2024-01-01" \
  --limit=20

# Find documentation improvements
gh search issues "documentation" \
  --label="good first issue" \
  --state=open \
  --no-assignee

# Find bug fixes in specific ecosystem
gh search issues "bug" \
  --language=python \
  --label="hacktoberfest" \
  --repo-topic="machine-learning"

# Contributing to [Project Name]

First off, thank you for considering contributing to [Project Name]! It's people like you that make [Project Name] such a great tool.

## Code of Conduct

This project and everyone participating in it is governed by the [Project Name Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code.

## How Can I Contribute?

### Reporting Bugs

Before creating bug reports, please check [this list](#before-submitting-a-bug-report) as you might find out that you don't need to create one.

#### Before Submitting A Bug Report

- **Check the [FAQ](link)** for a list of common questions and problems.
- **Perform a [cursory search](link)** to see if the problem has already been reported.
- **Check if the issue has been fixed** — try to reproduce it using the latest `main` branch.

#### How Do I Submit A Good Bug Report?

Bugs are tracked as [GitHub issues](link). Create an issue and provide the following information:

- **Use a clear and descriptive title**
- **Describe the exact steps which reproduce the problem**
- **Provide specific examples to demonstrate the steps**
- **Describe the behavior you observed after following the steps**
- **Explain which behavior you expected to see instead and why**
- **Include screenshots and animated GIFs** if possible
- **Include crash reports with stack traces**
- **Include your environment details**

### Suggesting Enhancements

#### Before Submitting An Enhancement Suggestion

- **Check if there's already a package** which provides that enhancement.
- **Perform a [cursory search](link)** to see if the enhancement has already been suggested.

#### How Do I Submit A Good Enhancement Suggestion?

Enhancement suggestions are tracked as [GitHub issues](link). Create an issue and provide:

- **Use a clear and descriptive title**
- **Provide a step-by-step description of the suggested enhancement**
- **Provide specific examples to demonstrate the steps**
- **Describe the current behavior** and **explain which behavior you expected to see instead**
- **Explain why this enhancement would be useful**
- **List some other projects where this enhancement exists**

### Your First Code Contribution

Unsure where to begin contributing? You can start by looking through these `beginner` and `help-wanted` issues:

- [Beginner issues](link) - issues which should only require a few lines of code
- [Help wanted issues](link) - issues which should be a bit more involved

### Pull Request Process

1. **Fork the repo** and create your branch from `main`.
2. **If you've added code** that should be tested, add tests.
3. **If you've changed APIs**, update the documentation.
4. **Ensure the test suite passes**.
5. **Make sure your code lints**.
6. **Issue that pull request!**

### Development Process

1. **Set up your development environment**
   __CODE_BLOCK_20__`

2. **Make your changes**
   * Write meaningful commit messages
   * Include tests for new functionality
   * Update documentation as needed

3. **Verify your changes**
   ```bash
   npm run lint      # Check code style
   npm run test      # Run tests
   npm run build     # Build the project
   ```

### Style Guides

#### Git Commit Messages

* Use the present tense ("Add feature" not "Added feature")
* Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
* Limit the first line to 72 characters or less
* Reference issues and pull requests liberally after the first line
* Follow [Conventional Commits](https://www.conventionalcommits.org/)

#### JavaScript Style Guide

* All JavaScript must adhere to [JavaScript Standard Style](https://standardjs.com/)
* Prefer ES6+ features when possible
* Use meaningful variable names
* Document complex logic

#### Documentation Style Guide

* Use [Markdown](https://guides.github.com/features/mastering-markdown/)
* Reference functions and classes in backticks: \`functionName()\`
* Include code examples for new features

## Recognition

### Contributors

We use [All Contributors](https://allcontributors.org/) to recognize all contributions.

### Types of Contributions

* 💻 Code
* 📖 Documentation
* 🎨 Design
* 💡 Examples
* 🔧 Maintenance
* 🧪 Tests
* 🔍 Review
* 💬 Questions

## Questions?

Feel free to [open an issue](link) with your question or contact the maintainers directly.

Thank you! ❤️

```

> **💡 💡 Pro Tip**
> Before contributing to a new project, spend time understanding their workflow by reviewing recently merged PRs and closed issues.

## Part 7: Team Communication Standards

### 🏢 Real-World Application
**Scenario:** Distributed team working across time zones
**Solution:** Established communication protocols and documentation
**Impact:** Efficient collaboration without constant meetings

### Asynchronous Communication Best Practices

#### PR Communication Timeline

```

graph LR
A\[PR Created] -->|24h| B\[Initial Review]
B -->|48h| C\[Author Response]
C -->|24h| D\[Final Review]
D -->|12h| E\[Merge/Close]

```

#### Professional Comment Templates

```

## Blocking Issue Found

@author This PR has a blocking issue that needs resolution:

**Issue:** \[Specific problem]
**Impact:** \[Why it blocks merging]
**Suggested Fix:** \[Potential solution]

Please address this before we can proceed with the review.

## Non-Blocking Suggestions

These are suggestions that would improve the code but aren't blocking:

1. **Performance:** Consider using \[approach] for better performance
2. **Readability:** This section could benefit from \[improvement]
3. **Future-proofing:** Think about \[consideration] for scalability

Feel free to address these in this PR or create a follow-up issue.

## Ready to Merge

LGTM! 🚀

**What I particularly liked:**

* Clean implementation of \[feature]
* Good test coverage
* Clear documentation

**Minor notes for future PRs:**

* Consider \[small improvement] next time

Approving and ready to merge once CI passes.

```

### Exercise 7: Establishing Team Workflows

#### Create Team Agreement Document

```

# Team Collaboration Agreement

## Response Times

* **PR Reviews:** Within 24 hours during business days
* **Blocking Issues:** Within 4 hours during business hours
* **General Questions:** Within 48 hours

## Code Review Standards

* Minimum 1 approval required for merge
* Author cannot approve own PR
* CI must pass before merge
* No force pushes to main branch

## Communication Channels

* **Urgent:** Slack #dev-urgent
* **PR Discussions:** GitHub comments
* **Design Decisions:** GitHub Discussions
* **Daily Updates:** Slack #dev-standup

## Meeting Schedule

* **Stand-up:** Daily 10am UTC (async friendly)
* **Sprint Planning:** Biweekly Monday 2pm UTC
* **Retrospective:** Biweekly Friday 3pm UTC

## Documentation Requirements

* All PRs must update relevant docs
* Architecture decisions in ADR format
* API changes require changelog entry
* Breaking changes need migration guide

```

### Managing Conflicts and Disagreements

#### Conflict Resolution Framework

```

## Technical Disagreement Process

1. **Document Positions**
   * Each party writes their approach
   * Include pros/cons analysis
   * Provide benchmarks if applicable

2. **Seek Third Opinion**
   * Involve senior team member
   * Consider architecture team input
   * Review against team standards

3. **Decision Making**
   * Data-driven approach preferred
   * Consider long-term maintenance
   * Document decision rationale

4. **Moving Forward**
   * Commit to decision as team
   * Create follow-up tickets if needed
   * Review in retrospective

## Example Resolution

### Disagreement: REST vs GraphQL for new API

**Position A: REST**

* Simpler to implement
* Better caching
* Team expertise

**Position B: GraphQL**

* Flexible queries
* Reduced over-fetching
* Modern standard

**Resolution:** Use REST for v1, plan GraphQL evaluation for v2
**Rationale:** Team expertise and timeline constraints
**Follow-up:** Create spike ticket for GraphQL POC

```

> **💡 💡 Pro Tip**
> Document all significant technical decisions in Architecture Decision Records (ADRs) stored in your repository. This provides context for future team members.

## 🔨 Workshop Deliverables

### Practical Exercise: Complete Team Collaboration Cycle

Complete the following professional collaboration workflow:

1. **Fork and Setup** (30 minutes)
   - Fork the workshop repository
   - Configure remotes properly
   - Set up branch protection rules
   - Create issue and PR templates

2. **Feature Development** (45 minutes)
   - Create a well-scoped issue
   - Develop feature on properly named branch
   - Write comprehensive PR description
   - Include tests and documentation

3. **Code Review** (45 minutes)
   - Review at least 2 peer PRs
   - Provide constructive feedback
   - Respond to feedback on your PR
   - Iterate based on reviews

4. **Project Management** (30 minutes)
   - Set up a project board
   - Create and organize issues
   - Link PRs to issues
   - Track progress through workflow

### Submission Checklist

<details>
<summary>🔖 Required Deliverables</summary>

#### Technical Artifacts
- [ ] Forked repository with proper setup
- [ ] At least one merged pull request
- [ ] Two code reviews performed
- [ ] Project board with 5+ issues
- [ ] Contributing guidelines created

#### Documentation
- [ ] Team collaboration agreement
- [ ] Architecture decision record (ADR)
- [ ] Code review checklist
- [ ] PR template implemented

#### Reflection Report (500 words)
Address the following:
1. Most valuable collaboration practice learned
2. Challenges faced and solutions
3. How you'll apply these skills professionally
4. Your open source contribution goals

</details>

### Assessment Criteria

| Aspect | Weight | Criteria |
|--------|--------|----------|
| Technical Execution | 40% | Proper Git workflow, clean commits, successful merges |
| Communication | 30% | Clear PR descriptions, constructive reviews, professional tone |
| Documentation | 20% | Comprehensive, well-structured, follows standards |
| Collaboration | 10% | Active participation, helpful feedback, team player |

## ⚠️ Common Pitfalls and Solutions

| Pitfall | Impact | Solution |
|---------|--------|----------|
| Large, unfocused PRs | Difficult to review | Keep PRs under 400 lines |
| Vague commit messages | Poor history | Use conventional commits |
| Ignoring CI failures | Broken builds | Fix before requesting review |
| Delayed responses | Blocked teammates | Set up notifications |
| Merge conflicts | Integration issues | Rebase frequently |

## 🔧 Troubleshooting Guide

### Merge Conflict Resolution

```

# When conflicts occur during rebase

git rebase upstream/main

# Fix conflicts in editor

git add .
git rebase --continue

# For complex conflicts

git rebase --abort
git merge upstream/main  # Easier to resolve

```

### Accidentally Pushed to Wrong Branch

```

# Create backup branch

git branch backup-branch

# Reset to previous state

git reset --hard HEAD\~1

# Force push (only on your fork!)

git push --force-with-lease origin branch-name

```

### PR Shows Too Many Changes

```

# Ensure your main is up to date

git checkout main
git pull upstream main
git push origin main

# Rebase your feature branch

git checkout feature-branch
git rebase main
git push --force-with-lease origin feature-branch

```

## 📚 Additional Resources

### Official Documentation
- **GitHub Docs:** [Collaborating with pull requests](https://docs.github.com/en/pull-requests)
- **Git Documentation:** [Pro Git Book](https://git-scm.com/book/en/v2)
- **Conventional Commits:** [Specification](https://www.conventionalcommits.org/)
- **Semantic Versioning:** [SemVer Spec](https://semver.org/)

### Professional Development
- **Code Review Best Practices:** [Google's Engineering Practices](https://google.github.io/eng-practices/review/)
- **Open Source Guide:** [How to Contribute](https://opensource.guide/how-to-contribute/)
- **GitHub Skills:** [Interactive Courses](https://skills.github.com/)
- **The Carpentries:** [Git Collaboration Lesson](https://swcarpentry.github.io/git-novice/)

### Tools and Extensions
- **GitHub CLI:** Streamline workflow from terminal
- **GitHub Desktop:** Visual Git client
- **Refined GitHub:** Browser extension for enhanced UI
- **Octotree:** Code tree for GitHub

### Community Resources
- **First Timers Only:** Beginner-friendly issues
- **Good First Issue:** Curated starter issues
- **CodeTriage:** Help maintain open source projects
- **24 Pull Requests:** December open source challenge

## Next Steps

After completing this workshop, consider:

1. **Advanced Git Workflows**
   - Git flow and GitHub flow strategies
   - Advanced rebasing and cherry-picking
   - Submodules and subtrees
   - Git hooks and automation

2. **CI/CD Integration**
   - GitHub Actions workflows
   - Automated testing pipelines
   - Deployment strategies
   - Security scanning

3. **Open Source Contribution**
   - Find projects in your area of interest
   - Start with documentation improvements
   - Graduate to feature development
   - Consider maintaining a project

4. **Team Leadership**
   - Establish team workflows
   - Mentor junior developers
   - Lead code review sessions
   - Drive technical decisions

---

**Remember:** Professional collaboration is a skill that improves with practice. Start small, be consistent, and always focus on clear communication and mutual respect.
```