Release v1.22.0: Add skill-reviewer and github-contributor
- Add skill-reviewer v1.0.0 for reviewing Claude Code skills against best practices - Self-review mode: validate your own skills before publishing - External review mode: evaluate others' skill repositories - Auto-PR mode: fork, improve, submit PRs with additive-only changes - Auto-install dependencies: automatically installs skill-creator if missing - Add github-contributor v1.0.0 for strategic open-source contribution - Four contribution types: Documentation, Code Quality, Bug Fixes, Features - Project selection criteria and red flags - PR excellence workflow and reputation building ladder - GitHub CLI commands and conventional commit format - Update marketplace to v1.22.0 with 30 skills - Update documentation (README, README.zh-CN, CLAUDE.md, CHANGELOG) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
daymade
4
github-contributor/.security-scan-passed
Normal file
4
github-contributor/.security-scan-passed
Normal file
@@ -0,0 +1,4 @@
|
||||
Security scan passed
|
||||
Scanned at: 2026-01-15T23:00:17.980955
|
||||
Tool: gitleaks + pattern-based validation
|
||||
Content hash: 29b45018317a2ccdcf345364026e3a309a9a997ab493efb587944af6ec1de020
|
||||
260
github-contributor/SKILL.md
Normal file
260
github-contributor/SKILL.md
Normal file
@@ -0,0 +1,260 @@
|
||||
---
|
||||
name: github-contributor
|
||||
description: Strategic guide for becoming an effective GitHub contributor. Covers opportunity discovery, project selection, high-quality PR creation, and reputation building. Use when looking to contribute to open-source projects, building GitHub presence, or learning contribution best practices.
|
||||
---
|
||||
|
||||
# GitHub Contributor
|
||||
|
||||
Strategic guide for becoming an effective GitHub contributor and building your open-source reputation.
|
||||
|
||||
## The Strategy
|
||||
|
||||
**Core insight**: Many open-source projects have room for improvement. By contributing high-quality PRs, you:
|
||||
- Build contributor reputation
|
||||
- Learn from top codebases
|
||||
- Expand professional network
|
||||
- Create public proof of skills
|
||||
|
||||
## Contribution Types
|
||||
|
||||
### 1. Documentation Improvements
|
||||
|
||||
**Lowest barrier, high impact.**
|
||||
|
||||
- Fix typos, grammar, unclear explanations
|
||||
- Add missing examples
|
||||
- Improve README structure
|
||||
- Translate documentation
|
||||
|
||||
```
|
||||
Opportunity signals:
|
||||
- "docs", "documentation" labels
|
||||
- Issues asking "how do I..."
|
||||
- Outdated screenshots or examples
|
||||
```
|
||||
|
||||
### 2. Code Quality Enhancements
|
||||
|
||||
**Medium effort, demonstrates technical skill.**
|
||||
|
||||
- Fix linter warnings
|
||||
- Add type annotations
|
||||
- Improve error messages
|
||||
- Refactor for readability
|
||||
|
||||
```
|
||||
Opportunity signals:
|
||||
- "good first issue" label
|
||||
- "tech debt" or "refactor" labels
|
||||
- Code without tests
|
||||
```
|
||||
|
||||
### 3. Bug Fixes
|
||||
|
||||
**High impact, builds trust.**
|
||||
|
||||
- Reproduce and fix reported bugs
|
||||
- Add regression tests
|
||||
- Document root cause
|
||||
|
||||
```
|
||||
Opportunity signals:
|
||||
- "bug" label with reproduction steps
|
||||
- Issues with many thumbs up
|
||||
- Stale bugs (maintainers busy)
|
||||
```
|
||||
|
||||
### 4. Feature Additions
|
||||
|
||||
**Highest effort, highest visibility.**
|
||||
|
||||
- Implement requested features
|
||||
- Add integrations
|
||||
- Performance improvements
|
||||
|
||||
```
|
||||
Opportunity signals:
|
||||
- "help wanted" label
|
||||
- Features with clear specs
|
||||
- Issues linked to roadmap
|
||||
```
|
||||
|
||||
## Project Selection
|
||||
|
||||
### Good First Projects
|
||||
|
||||
| Criteria | Why |
|
||||
|----------|-----|
|
||||
| Active maintainers | PRs get reviewed |
|
||||
| Clear contribution guide | Know expectations |
|
||||
| "good first issue" labels | Curated entry points |
|
||||
| Recent merged PRs | Project is alive |
|
||||
| Friendly community | Supportive feedback |
|
||||
|
||||
### Red Flags
|
||||
|
||||
- No activity in 6+ months
|
||||
- Many open PRs without review
|
||||
- Hostile issue discussions
|
||||
- No contribution guidelines
|
||||
|
||||
### Finding Projects
|
||||
|
||||
```bash
|
||||
# GitHub search for good first issues
|
||||
gh search issues "good first issue" --language=python --sort=created
|
||||
|
||||
# Search by topic
|
||||
gh search repos "topic:cli" --sort=stars --limit=20
|
||||
|
||||
# Find repos you use
|
||||
# Check dependencies in your projects
|
||||
```
|
||||
|
||||
## PR Excellence
|
||||
|
||||
### Before Writing Code
|
||||
|
||||
```
|
||||
Pre-PR Checklist:
|
||||
- [ ] Read CONTRIBUTING.md
|
||||
- [ ] Check existing PRs for similar changes
|
||||
- [ ] Comment on issue to claim it
|
||||
- [ ] Understand project conventions
|
||||
- [ ] Set up development environment
|
||||
```
|
||||
|
||||
### Writing the PR
|
||||
|
||||
**Title**: Clear, conventional format
|
||||
|
||||
```
|
||||
feat: Add support for YAML config files
|
||||
fix: Resolve race condition in connection pool
|
||||
docs: Update installation instructions for Windows
|
||||
refactor: Extract validation logic into separate module
|
||||
```
|
||||
|
||||
**Description**: Structured and thorough
|
||||
|
||||
```markdown
|
||||
## Summary
|
||||
[What this PR does in 1-2 sentences]
|
||||
|
||||
## Motivation
|
||||
[Why this change is needed]
|
||||
|
||||
## Changes
|
||||
- [Change 1]
|
||||
- [Change 2]
|
||||
|
||||
## Testing
|
||||
[How you tested this]
|
||||
|
||||
## Screenshots (if UI)
|
||||
[Before/After images]
|
||||
```
|
||||
|
||||
### After Submitting
|
||||
|
||||
- Respond to feedback promptly
|
||||
- Make requested changes quickly
|
||||
- Be grateful for reviews
|
||||
- Don't argue, discuss
|
||||
|
||||
## Building Reputation
|
||||
|
||||
### The Contribution Ladder
|
||||
|
||||
```
|
||||
Level 1: Documentation fixes
|
||||
↓ (build familiarity)
|
||||
Level 2: Small bug fixes
|
||||
↓ (understand codebase)
|
||||
Level 3: Feature contributions
|
||||
↓ (trusted contributor)
|
||||
Level 4: Maintainer status
|
||||
```
|
||||
|
||||
### Consistency Over Volume
|
||||
|
||||
```
|
||||
❌ 10 PRs in one week, then nothing
|
||||
✅ 1-2 PRs per week, sustained
|
||||
```
|
||||
|
||||
### Engage Beyond PRs
|
||||
|
||||
- Answer questions in issues
|
||||
- Help triage bug reports
|
||||
- Review others' PRs (if welcome)
|
||||
- Join project Discord/Slack
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
### Don't
|
||||
|
||||
- Submit drive-by PRs without context
|
||||
- Argue with maintainers
|
||||
- Ignore code style guidelines
|
||||
- Make massive changes without discussion
|
||||
- Ghost after submitting
|
||||
|
||||
### Do
|
||||
|
||||
- Start with small, focused PRs
|
||||
- Follow project conventions exactly
|
||||
- Communicate proactively
|
||||
- Accept feedback gracefully
|
||||
- Build relationships over time
|
||||
|
||||
## Workflow Template
|
||||
|
||||
```
|
||||
Contribution Workflow:
|
||||
- [ ] Find project with "good first issue"
|
||||
- [ ] Read contribution guidelines
|
||||
- [ ] Comment on issue to claim
|
||||
- [ ] Fork and set up locally
|
||||
- [ ] Make focused changes
|
||||
- [ ] Test thoroughly
|
||||
- [ ] Write clear PR description
|
||||
- [ ] Respond to review feedback
|
||||
- [ ] Celebrate when merged! 🎉
|
||||
```
|
||||
|
||||
## Quick Reference
|
||||
|
||||
### GitHub CLI Commands
|
||||
|
||||
```bash
|
||||
# Fork a repo
|
||||
gh repo fork owner/repo --clone
|
||||
|
||||
# Create PR
|
||||
gh pr create --title "feat: ..." --body "..."
|
||||
|
||||
# Check PR status
|
||||
gh pr status
|
||||
|
||||
# View project issues
|
||||
gh issue list --repo owner/repo --label "good first issue"
|
||||
```
|
||||
|
||||
### Commit Message Format
|
||||
|
||||
```
|
||||
<type>(<scope>): <description>
|
||||
|
||||
[optional body]
|
||||
|
||||
[optional footer]
|
||||
```
|
||||
|
||||
Types: `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`
|
||||
|
||||
## References
|
||||
|
||||
- `references/pr_checklist.md` - Complete PR quality checklist
|
||||
- `references/project_evaluation.md` - How to evaluate projects
|
||||
- `references/communication_templates.md` - Issue/PR templates
|
||||
228
github-contributor/references/communication_templates.md
Normal file
228
github-contributor/references/communication_templates.md
Normal file
@@ -0,0 +1,228 @@
|
||||
# Communication Templates
|
||||
|
||||
Templates for effective open-source communication.
|
||||
|
||||
## Claiming an Issue
|
||||
|
||||
### First-Time Contributor
|
||||
|
||||
```markdown
|
||||
Hi! I'm interested in working on this issue.
|
||||
|
||||
I'm new to the project but I've read the contributing guidelines and set up the development environment. I think I understand the scope of the change needed.
|
||||
|
||||
My approach would be to:
|
||||
1. [Step 1]
|
||||
2. [Step 2]
|
||||
3. [Step 3]
|
||||
|
||||
Does this sound reasonable? Any guidance would be appreciated!
|
||||
```
|
||||
|
||||
### Experienced Contributor
|
||||
|
||||
```markdown
|
||||
I'd like to take this on.
|
||||
|
||||
Proposed approach:
|
||||
- [Technical approach]
|
||||
- [Testing strategy]
|
||||
|
||||
ETA: [timeframe]
|
||||
|
||||
Let me know if there are any concerns or if someone else is already working on this.
|
||||
```
|
||||
|
||||
## Asking for Clarification
|
||||
|
||||
```markdown
|
||||
Thanks for filing this issue!
|
||||
|
||||
I'd like to work on this but need some clarification:
|
||||
|
||||
1. [Question 1]
|
||||
2. [Question 2]
|
||||
|
||||
Once I understand these points, I can start on a fix.
|
||||
```
|
||||
|
||||
## PR Description
|
||||
|
||||
### Bug Fix
|
||||
|
||||
```markdown
|
||||
## Summary
|
||||
|
||||
Fixes #[issue number]
|
||||
|
||||
This PR resolves the [bug description] by [solution approach].
|
||||
|
||||
## Root Cause
|
||||
|
||||
The issue was caused by [explanation].
|
||||
|
||||
## Solution
|
||||
|
||||
[Detailed explanation of the fix]
|
||||
|
||||
## Testing
|
||||
|
||||
- [x] Added regression test
|
||||
- [x] Verified fix locally
|
||||
- [x] All existing tests pass
|
||||
|
||||
## Screenshots (if applicable)
|
||||
|
||||
Before:
|
||||
[image]
|
||||
|
||||
After:
|
||||
[image]
|
||||
```
|
||||
|
||||
### Feature Addition
|
||||
|
||||
```markdown
|
||||
## Summary
|
||||
|
||||
Implements #[issue number]
|
||||
|
||||
Adds [feature description] to enable [use case].
|
||||
|
||||
## Changes
|
||||
|
||||
- Added `feature.py` with [functionality]
|
||||
- Updated `config.py` to support [new option]
|
||||
- Added tests in `test_feature.py`
|
||||
|
||||
## Usage
|
||||
|
||||
```python
|
||||
# Example usage
|
||||
from project import new_feature
|
||||
result = new_feature(...)
|
||||
```
|
||||
|
||||
## Testing
|
||||
|
||||
- [x] Unit tests added
|
||||
- [x] Integration tests pass
|
||||
- [x] Documentation updated
|
||||
|
||||
## Migration Guide (if breaking)
|
||||
|
||||
[Instructions for users to migrate]
|
||||
```
|
||||
|
||||
### Documentation Update
|
||||
|
||||
```markdown
|
||||
## Summary
|
||||
|
||||
Improves documentation for [area].
|
||||
|
||||
## Changes
|
||||
|
||||
- Fixed typos in [file]
|
||||
- Added examples for [feature]
|
||||
- Updated outdated [section]
|
||||
- Clarified [confusing part]
|
||||
|
||||
## Preview
|
||||
|
||||
[Screenshot or link to rendered docs]
|
||||
```
|
||||
|
||||
## Responding to Reviews
|
||||
|
||||
### Accepting Feedback
|
||||
|
||||
```markdown
|
||||
Good catch! I've updated the code to [change].
|
||||
|
||||
See commit [hash].
|
||||
```
|
||||
|
||||
### Explaining a Decision
|
||||
|
||||
```markdown
|
||||
Thanks for the review!
|
||||
|
||||
I chose this approach because:
|
||||
1. [Reason 1]
|
||||
2. [Reason 2]
|
||||
|
||||
However, I'm open to changing it if you think [alternative] would be better. What do you think?
|
||||
```
|
||||
|
||||
### Requesting Clarification
|
||||
|
||||
```markdown
|
||||
Thanks for the feedback!
|
||||
|
||||
Could you clarify what you mean by [quote]? I want to make sure I address your concern correctly.
|
||||
```
|
||||
|
||||
### Disagreeing Respectfully
|
||||
|
||||
```markdown
|
||||
I see your point about [concern].
|
||||
|
||||
I went with the current approach because [reasoning]. However, I understand the tradeoff you're highlighting.
|
||||
|
||||
Would a middle ground like [alternative] address your concern while keeping [benefit]?
|
||||
```
|
||||
|
||||
## After Merge
|
||||
|
||||
```markdown
|
||||
Thanks for the review and merge! 🎉
|
||||
|
||||
I learned [something] from the feedback - I'll apply that in future contributions.
|
||||
|
||||
Looking forward to contributing more to the project!
|
||||
```
|
||||
|
||||
## Abandoning a PR
|
||||
|
||||
```markdown
|
||||
Hi, I won't be able to complete this PR due to [reason].
|
||||
|
||||
I've pushed my current progress in case someone else wants to continue from here. The remaining work is:
|
||||
- [ ] [Task 1]
|
||||
- [ ] [Task 2]
|
||||
|
||||
Sorry for any inconvenience, and thanks for the opportunity to contribute!
|
||||
```
|
||||
|
||||
## Tone Guidelines
|
||||
|
||||
### Always
|
||||
|
||||
- Be grateful
|
||||
- Be specific
|
||||
- Be patient
|
||||
- Be humble
|
||||
|
||||
### Never
|
||||
|
||||
- Be defensive
|
||||
- Be dismissive
|
||||
- Be demanding
|
||||
- Be passive-aggressive
|
||||
|
||||
### Word Choice
|
||||
|
||||
```
|
||||
❌ "You should..."
|
||||
✅ "It might help to..."
|
||||
|
||||
❌ "This is wrong"
|
||||
✅ "I think there might be an issue with..."
|
||||
|
||||
❌ "Obviously..."
|
||||
✅ "One approach could be..."
|
||||
|
||||
❌ "Why didn't you..."
|
||||
✅ "Could you help me understand..."
|
||||
```
|
||||
155
github-contributor/references/pr_checklist.md
Normal file
155
github-contributor/references/pr_checklist.md
Normal file
@@ -0,0 +1,155 @@
|
||||
# PR Quality Checklist
|
||||
|
||||
Complete checklist for creating high-quality pull requests.
|
||||
|
||||
## Before Starting
|
||||
|
||||
- [ ] Read CONTRIBUTING.md thoroughly
|
||||
- [ ] Check for existing PRs addressing same issue
|
||||
- [ ] Comment on issue to express interest
|
||||
- [ ] Wait for maintainer acknowledgment (if required)
|
||||
- [ ] Understand project's code style
|
||||
|
||||
## Environment Setup
|
||||
|
||||
- [ ] Fork repository
|
||||
- [ ] Clone to local machine
|
||||
- [ ] Set up development environment
|
||||
- [ ] Run existing tests (ensure they pass)
|
||||
- [ ] Create feature branch with descriptive name
|
||||
|
||||
```bash
|
||||
# Branch naming conventions
|
||||
feature/add-yaml-support
|
||||
fix/resolve-connection-timeout
|
||||
docs/update-installation-guide
|
||||
refactor/extract-validation-logic
|
||||
```
|
||||
|
||||
## During Development
|
||||
|
||||
- [ ] Make small, focused commits
|
||||
- [ ] Follow project's commit message format
|
||||
- [ ] Add tests for new functionality
|
||||
- [ ] Update documentation if needed
|
||||
- [ ] Run linter/formatter before committing
|
||||
|
||||
## Before Submitting
|
||||
|
||||
### Code Quality
|
||||
|
||||
- [ ] All tests pass
|
||||
- [ ] No linter warnings
|
||||
- [ ] Code follows project style
|
||||
- [ ] No unnecessary changes (whitespace, imports)
|
||||
- [ ] Comments explain "why", not "what"
|
||||
|
||||
### Documentation
|
||||
|
||||
- [ ] README updated (if applicable)
|
||||
- [ ] API docs updated (if applicable)
|
||||
- [ ] Inline comments added for complex logic
|
||||
- [ ] CHANGELOG updated (if required)
|
||||
|
||||
### PR Description
|
||||
|
||||
- [ ] Clear, descriptive title
|
||||
- [ ] Summary of changes
|
||||
- [ ] Motivation/context
|
||||
- [ ] Testing approach
|
||||
- [ ] Screenshots (for UI changes)
|
||||
- [ ] Related issues linked
|
||||
|
||||
## PR Title Format
|
||||
|
||||
```
|
||||
<type>(<scope>): <description>
|
||||
|
||||
Examples:
|
||||
feat(api): add support for batch requests
|
||||
fix(auth): resolve token refresh race condition
|
||||
docs(readme): add troubleshooting section
|
||||
refactor(utils): simplify date parsing logic
|
||||
test(api): add integration tests for search endpoint
|
||||
chore(deps): update lodash to 4.17.21
|
||||
```
|
||||
|
||||
## PR Description Template
|
||||
|
||||
```markdown
|
||||
## Summary
|
||||
|
||||
Brief description of what this PR does.
|
||||
|
||||
## Motivation
|
||||
|
||||
Why is this change needed? Link to issue if applicable.
|
||||
|
||||
Closes #123
|
||||
|
||||
## Changes
|
||||
|
||||
- Change 1
|
||||
- Change 2
|
||||
- Change 3
|
||||
|
||||
## Testing
|
||||
|
||||
How did you test this change?
|
||||
|
||||
- [ ] Unit tests added/updated
|
||||
- [ ] Manual testing performed
|
||||
- [ ] Integration tests pass
|
||||
|
||||
## Screenshots (if applicable)
|
||||
|
||||
| Before | After |
|
||||
|--------|-------|
|
||||
| image | image |
|
||||
|
||||
## Checklist
|
||||
|
||||
- [ ] Tests pass
|
||||
- [ ] Documentation updated
|
||||
- [ ] Code follows project style
|
||||
```
|
||||
|
||||
## After Submitting
|
||||
|
||||
- [ ] Monitor for CI results
|
||||
- [ ] Respond to review comments promptly
|
||||
- [ ] Make requested changes quickly
|
||||
- [ ] Thank reviewers for their time
|
||||
- [ ] Don't force push after review starts (unless asked)
|
||||
|
||||
## Review Response Etiquette
|
||||
|
||||
### Good Responses
|
||||
|
||||
```
|
||||
"Good point! I've updated the implementation to..."
|
||||
|
||||
"Thanks for catching that. Fixed in commit abc123."
|
||||
|
||||
"I see what you mean. I chose this approach because...
|
||||
Would you prefer if I changed it to...?"
|
||||
```
|
||||
|
||||
### Avoid
|
||||
|
||||
```
|
||||
"That's just your opinion."
|
||||
|
||||
"It works on my machine."
|
||||
|
||||
"This is how I always do it."
|
||||
```
|
||||
|
||||
## Common Rejection Reasons
|
||||
|
||||
1. **Too large** - Break into smaller PRs
|
||||
2. **Unrelated changes** - Remove scope creep
|
||||
3. **Missing tests** - Add test coverage
|
||||
4. **Style violations** - Run formatter
|
||||
5. **No issue link** - Create or link issue first
|
||||
6. **Conflicts** - Rebase on latest main
|
||||
149
github-contributor/references/project_evaluation.md
Normal file
149
github-contributor/references/project_evaluation.md
Normal file
@@ -0,0 +1,149 @@
|
||||
# Project Evaluation Guide
|
||||
|
||||
How to evaluate open-source projects before contributing.
|
||||
|
||||
## Quick Health Check
|
||||
|
||||
```bash
|
||||
# Check recent activity
|
||||
gh repo view owner/repo --json updatedAt,stargazersCount,openIssues
|
||||
|
||||
# Check PR response time
|
||||
gh pr list --repo owner/repo --state merged --limit 10
|
||||
|
||||
# Check issue activity
|
||||
gh issue list --repo owner/repo --limit 20
|
||||
```
|
||||
|
||||
## Evaluation Criteria
|
||||
|
||||
### 1. Activity Level
|
||||
|
||||
| Signal | Good | Bad |
|
||||
|--------|------|-----|
|
||||
| Last commit | < 1 month | > 6 months |
|
||||
| Open PRs | Being reviewed | Ignored |
|
||||
| Issue responses | Within days | Never |
|
||||
| Release frequency | Regular | Years ago |
|
||||
|
||||
### 2. Community Health
|
||||
|
||||
| Signal | Good | Bad |
|
||||
|--------|------|-----|
|
||||
| CONTRIBUTING.md | Exists, detailed | Missing |
|
||||
| Code of Conduct | Present | Missing |
|
||||
| Issue templates | Well-structured | None |
|
||||
| Discussion tone | Friendly, helpful | Hostile |
|
||||
|
||||
### 3. Maintainer Engagement
|
||||
|
||||
| Signal | Good | Bad |
|
||||
|--------|------|-----|
|
||||
| Review comments | Constructive | Dismissive |
|
||||
| Response time | Days | Months |
|
||||
| Merge rate | Regular merges | Stale PRs |
|
||||
| New contributor PRs | Welcomed | Ignored |
|
||||
|
||||
### 4. Documentation Quality
|
||||
|
||||
| Signal | Good | Bad |
|
||||
|--------|------|-----|
|
||||
| README | Clear, comprehensive | Minimal |
|
||||
| Getting started | Easy to follow | Missing |
|
||||
| API docs | Complete | Outdated |
|
||||
| Examples | Working, relevant | Broken |
|
||||
|
||||
## Scoring System
|
||||
|
||||
Rate each category 1-5:
|
||||
|
||||
```
|
||||
Activity Level: _/5
|
||||
Community Health: _/5
|
||||
Maintainer Engage: _/5
|
||||
Documentation: _/5
|
||||
----------------------------
|
||||
Total: _/20
|
||||
```
|
||||
|
||||
**Interpretation:**
|
||||
- 16-20: Excellent choice
|
||||
- 12-15: Good, proceed with caution
|
||||
- 8-11: Consider carefully
|
||||
- < 8: Avoid or expect delays
|
||||
|
||||
## Red Flags
|
||||
|
||||
### Immediate Disqualifiers
|
||||
|
||||
- No commits in 1+ year
|
||||
- Maintainer explicitly stepped away
|
||||
- Project archived
|
||||
- License issues
|
||||
|
||||
### Warning Signs
|
||||
|
||||
- Many open PRs without review
|
||||
- Hostile responses to contributors
|
||||
- No clear contribution path
|
||||
- Overly complex setup
|
||||
|
||||
## Green Flags
|
||||
|
||||
### Strong Indicators
|
||||
|
||||
- "good first issue" labels maintained
|
||||
- Active Discord/Slack community
|
||||
- Regular release schedule
|
||||
- Responsive maintainers
|
||||
- Clear roadmap
|
||||
|
||||
### Bonus Points
|
||||
|
||||
- Funded/sponsored project
|
||||
- Multiple active maintainers
|
||||
- Good test coverage
|
||||
- CI/CD pipeline
|
||||
|
||||
## Research Checklist
|
||||
|
||||
```
|
||||
Project Evaluation:
|
||||
- [ ] Check GitHub Insights
|
||||
- [ ] Read recent issues
|
||||
- [ ] Review merged PRs
|
||||
- [ ] Check contributor guide
|
||||
- [ ] Look for "good first issue"
|
||||
- [ ] Assess community tone
|
||||
- [ ] Verify active maintenance
|
||||
- [ ] Confirm compatible license
|
||||
```
|
||||
|
||||
## Finding Projects
|
||||
|
||||
### By Interest
|
||||
|
||||
```bash
|
||||
# Find by topic
|
||||
gh search repos "topic:cli" --sort=stars
|
||||
|
||||
# Find by language
|
||||
gh search repos "language:python" --sort=stars
|
||||
|
||||
# Find with good first issues
|
||||
gh search issues "good first issue" --language=rust
|
||||
```
|
||||
|
||||
### By Need
|
||||
|
||||
- Tools you use daily
|
||||
- Libraries in your projects
|
||||
- Frameworks you're learning
|
||||
- Problems you've encountered
|
||||
|
||||
### Curated Lists
|
||||
|
||||
- awesome-for-beginners
|
||||
- first-timers-only
|
||||
- up-for-grabs.net
|
||||
- goodfirstissue.dev
|
||||
Reference in New Issue
Block a user