Bài 24: Open Source Contribution — chọn repo phù hợp để đóng góp

Sau bài này, bạn sẽ:

• ✅ Biết lý do thực tế để đầu tư vào OSS contribution
• ✅ Chọn được repo phù hợp theo skill level hiện tại
• ✅ Đánh giá repo bằng checklist 8 tiêu chí trước khi commit thời gian
• ✅ Thực hiện đủ 7 bước để merge PR đầu tiên
• ✅ Tránh các anti-pattern phổ biến làm PR bị closed

OSS contribution không phải hoạt động tình nguyện không hồi đáp. Với AI Engineer đang xây portfolio, nó có lợi ích cụ thể:

Credibility có thể verify

PR merged vào popular project là bằng chứng skill thực tế mà recruiter và hiring manager có thể click vào xem trực tiếp. Không thể giả mạo, không phụ thuộc vào lời tự khai trên CV.

Học từ codebase production

Đọc code của scikit-learn, transformers hay langchain bạn sẽ thấy cách team expert tổ chức test, xử lý edge case, viết docstring, và maintain backward compatibility — những thứ không có trong tutorial.

Network với maintainer và contributor

Maintainer của Hugging Face transformers hay scikit-learn thường là researcher hoặc engineer kỳ cựu trong ngành. Tương tác nghiêm túc qua issue/PR là cách network thực chất hơn kết bạn LinkedIn mù quáng.

CV signal được hiring manager đánh giá cao

Nhiều hiring manager AI/ML tìm ứng viên có OSS contribution vì nó chứng minh bạn có thể làm việc trong codebase không do mình tạo ra — yêu cầu thực tế của mọi vị trí engineer.

LinkedIn recruiter search

Thêm "Open Source Contributor" vào LinkedIn About section hoặc Headline giúp bạn xuất hiện trong một số filter của recruiter technical.

OSS contribution có điều kiện tiên quyết. Bắt đầu quá sớm sẽ tốn nhiều thời gian hơn lợi ích thu được.

Nên start khi:

• Đã hoàn thành ít nhất 2–3 capstone project (Module 3 của series này)
• Thành thạo Git/GitHub workflow — fork, branch, PR, resolve conflict (bài 5–6)
• Đọc được codebase Python ở mức medium: hiểu class inheritance, decorator, type hint, pytest
• Có thể chạy test suite local và đọc hiểu test failure

Chưa nên start khi:

• Còn struggle với Python cơ bản hoặc Git conflict
• Chưa viết được unit test
• Chưa hiểu virtual environment / dependency management

Không có deadline cứng, nhưng thực tế nhiều người bắt đầu OSS sau 3–4 tháng học AI Engineering và đã có 1–2 project cá nhân.

Phân loại theo loại contribution, không phải theo repo name — cùng một repo có thể có issue ở nhiều tier khác nhau.

Tier 1 — Doc / Tutorial fix (dễ nhất)

Scope nhỏ, cycle review nhanh, ít risk bị reject vì lý do kỹ thuật:

• Sửa typo trong README hoặc docstring
• Thêm ví dụ code cho function chưa có example
• Dịch doc sang tiếng Việt (một số project có translation program)
• Cập nhật tutorial dùng API deprecated
• Cải thiện warning message hoặc error message để dễ hiểu hơn

Phù hợp cho PR đầu tiên. Hầu hết project có label documentation hoặc good first issue bao gồm loại này.

Tier 2 — Test / Type hints (trung bình)

Cần đọc code logic nhưng không cần thay đổi behavior:

• Thêm test case cho function chưa có coverage
• Thêm type hints (mypy strict) cho module chưa annotate
• Fix flaky test (test pass/fail không deterministic)
• Tăng coverage cho edge case chưa được test

Tier này giúp bạn đọc sâu hơn vào codebase và thường được maintainer đánh giá cao hơn doc fix.

Tier 3 — Bug fix / Small feature (khó hơn)

Yêu cầu hiểu logic và design của project:

• Fix bug đã có repro steps rõ ràng trong issue
• Implement feature nhỏ trong "good first issue" label
• Refactor module theo gợi ý của maintainer

Không nên pick issue Tier 3 cho PR đầu tiên. Bắt đầu bằng Tier 1–2 để quen với process review của project cụ thể.

Danh sách dựa trên mức độ welcoming với beginner contributor, không phải độ nổi tiếng của project.

Phù hợp cho beginner

Phù hợp sau khi có 2–3 PR đã merge

Tránh nếu mới bắt đầu

• PyTorch core: C++ extension, CUDA kernel, không phải Python thuần
• JAX: Research-grade, API changes thường xuyên
• CUDA-related lib: Cần background GPU programming

Trước khi đầu tư thời gian vào repo nào, chạy qua checklist sau. Repo không đạt đa số tiêu chí thường dẫn đến PR mở mãi không được review.

Checklist đánh giá repo OSS
════════════════════════════════════════════════
[ ] Active commits trong 30 ngày qua
    → Xem tab "Commits" hoặc GitHub Insights

[ ] Maintainer reply issue / PR trong 1 tuần
    → Xem 5–10 issue gần nhất, đọc comment

[ ] Có CONTRIBUTING.md
    → Không có = thiếu hướng dẫn, risk cao

[ ] Có "good first issue" hoặc "help wanted" label
    → Sign maintainer chủ động welcome beginner

[ ] Test suite chạy được local (không broken)
    → Clone → pip install -e ".[dev]" → pytest
    → Nếu CI fail mà không có response = red flag

[ ] License OSI-approved (Apache 2.0, MIT, BSD)
    → AGPL có thể conflict với employer policy
    → Kiểm tra file LICENSE ở root repo

[ ] CI pass mọi PR (không stale pending)
    → Xem "Actions" tab, PR list

[ ] Community welcoming
    → Đọc tone comment trong 3–5 PR gần nhất
    → Maintainer dismissive hoặc rude = tránh
════════════════════════════════════════════════

Một repo đạt 6/8 tiêu chí trở lên đáng để thử. Dưới 5 tiêu chí thì thời gian bỏ ra nhiều khả năng không cho kết quả.

Bước 1 — Tìm issue phù hợp

Filter issue trên GitHub:

• Label: good first issue hoặc help wanted
• Không có assignee (tránh duplicate effort)
• Scope khoảng 1–3 giờ làm việc cho PR đầu tiên
• Có comment từ maintainer xác nhận issue còn valid

Đọc kỹ issue description và toàn bộ comment thread trước khi claim. Nhiều issue có clarification quan trọng trong comment.

Bước 2 — Comment trước khi bắt tay làm

Viết comment ngắn trong issue:

Hi, I'd like to work on this. My plan:
- [mô tả cách bạn sẽ fix/implement]
- Expected to open a PR within [X days]

Let me know if this approach sounds right.

Chờ maintainer xác nhận hoặc assign. Không open PR mà không ping trước — một vài project reject PR drive-by theo policy.

Bước 3 — Fork và clone

# Fork qua GitHub UI hoặc gh CLI
gh repo fork OWNER/REPO --clone

cd REPO

# Add upstream remote để sync với repo gốc
git remote add upstream https://github.com/OWNER/REPO.git
git remote -v
# origin    https://github.com/YOUR_USERNAME/REPO.git (fetch)
# origin    https://github.com/YOUR_USERNAME/REPO.git (push)
# upstream  https://github.com/OWNER/REPO.git (fetch)
# upstream  https://github.com/OWNER/REPO.git (push)

Bước 4 — Setup môi trường dev

Đọc CONTRIBUTING.md trước — không đọc là lý do phổ biến nhất khiến PR bị reject vì format hoặc test thiếu.

# Tạo virtualenv riêng cho project
python -m venv .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate

# Cài dev dependencies (tên khác nhau tùy project)
pip install -e ".[dev]"
# hoặc
pip install -r requirements-dev.txt

# Chạy test để verify môi trường OK
pytest tests/ -x -q
# Tất cả test phải pass trước khi bắt đầu modify

Nếu test bị fail ngay khi chưa chạm code, báo cáo trong issue — có thể đây là bug CI cần fix riêng.

Bước 5 — Tạo branch và code

# Tên branch: loại/mô-tả-ngắn-issue-number
git checkout -b fix/handle-empty-input-1234
# hoặc
git checkout -b docs/add-example-tokenizer-456

# Sau khi fix, chạy lại test
pytest tests/

# Chạy linter nếu project yêu cầu
ruff check .
# hoặc
flake8 .
mypy src/

Không sửa file nào không liên quan đến issue. Formatting noise trong diff là lý do phổ biến khiến PR cần nhiều vòng review hơn.

Bước 6 — Commit và push

# Commit message reference issue number
git add path/to/changed/file.py
git commit -m "fix: handle empty input in tokenizer (#1234)"

# Hoặc theo convention của project cụ thể
# (đọc CONTRIBUTING.md — một số dùng Angular commit style)

git push origin fix/handle-empty-input-1234

Bước 7 — Mở Pull Request

PR description cần có đủ 4 phần:

## Summary
Fixes #1234

When tokenizer receives empty string input, it raises UnboundLocalError
instead of returning an empty list. This PR adds an early return for
empty input with a corresponding test.

## What changed
- `src/tokenizer.py`: added guard for empty string at line 42
- `tests/test_tokenizer.py`: added `test_empty_input` test case

## How tested
- `pytest tests/test_tokenizer.py -v` — all 12 tests pass
- Verified manually with `tokenize("")` returning `[]`

## Screenshot / output (nếu có UI)
N/A

Đợi CI pass trước khi request review. Maintainer thường không review PR có CI red.

Small PR — 1 PR = 1 logical change

Không trộn nhiều fix vào cùng một PR dù chúng nhỏ. PR nhỏ review nhanh hơn, ít conflict hơn, dễ revert hơn khi cần.

Test đi kèm với change

Mỗi bug fix nên có ít nhất 1 test verify bug đã fixed. Mỗi feature mới nên có test cover case chính. PR không có test thường bị request changes ngay lần review đầu.

Lint pass trước khi push

Chạy linter local — không để CI phát hiện lint error. Một vòng CI feedback mất thời gian và tạo cảm giác thiếu chú ý với maintainer.

Không reformat file không liên quan

Sửa typo trong file A nhưng đồng thời format lại 200 dòng của file B (dù style sai) sẽ làm diff noise và reviewer khó xác định đâu là thay đổi thực chất.

Đáp ứng review comment trong 24–48 giờ

Maintainer là volunteer. PR không phản hồi trong 1–2 tuần thường bị close do stale.

Review cycle là phần quan trọng nhất của OSS contribution — đây là nơi bạn học nhiều nhất.

Bị request changes

Implement theo comment của reviewer. Với mỗi comment đã xử lý, reply "Done" hoặc commit reference. Với comment chưa rõ, hỏi lại: "Could you clarify what you mean by X? I'm thinking of [approach] but unsure if that matches your intent."

Bị rejected (PR closed without merge)

Đọc kỹ lý do. Phần lớn rejection có lý do hợp lý: issue đã được fix theo cách khác, direction thay đổi, hoặc scope không phù hợp. Thank maintainer và move on.

Không argue về quyết định reject trừ khi có misunderstanding cụ thể cần clarify.

Không có phản hồi (silent PR)

Sau 1 tuần không có comment, ping lịch sự 1 lần: "Hi, just checking in on this PR. Let me know if there's anything I should update."

Nếu vẫn silent sau 2–3 tuần với repo bình thường active, có thể issue đó không được prioritize hoặc PR approach không phù hợp.

PR merged

Thank maintainer ngắn gọn. Ghi nhận feedback để áp dụng cho PR tiếp theo.

Danh sách lý do phổ biến khiến PR beginner bị reject hoặc bị ignore:

AI Engineer trái ngành có một lợi thế OSS mà người xuất phát từ CS thuần không có: domain knowledge.

Contribute vào project thuộc domain cũ của bạn thường cho outcome tốt hơn vì bạn hiểu use case thực tế:

Contribution vào pyhealth từ một bác sĩ mang nhiều giá trị domain hơn một random Python developer — cả maintainer lẫn employer đều nhận ra điều này.

Thay vì tự search GitHub, một số platform aggregator giúp tìm issue nhanh hơn:

• good-first-issue.com — aggregator issue beginner-friendly theo ngôn ngữ. Filter Python + AI-related label.
• firstcontributions.github.io — tutorial step-by-step từ fork đến PR merge, phù hợp để làm quen flow lần đầu.
• CodeTriage — subscribe nhận email daily với issue mới từ repo bạn theo dõi. Có thể set "issues per day" để không bị overwhelm.
• OpenSauced (opensauced.pizza) — profile platform tracking OSS contribution, hiển thị contribution history dạng portfolio.
• Up For Grabs (up-for-grabs.net) — list project có up-for-grabs label theo tag, filter Python dễ dàng.

GitHub search cũng dùng được trực tiếp:

is:open is:issue label:"good first issue" language:Python
# Thêm topic hoặc keyword để filter:
is:open is:issue label:"good first issue" language:Python topic:machine-learning

Hacktoberfest (tháng 10 hàng năm)

DigitalOcean tổ chức, nhiều project đăng ký tham gia. Contributor cần merge 4 PR trong tháng 10. Nhiều project gắn label hacktoberfest để welcome beginner.

Cảnh báo thực tế: Hacktoberfest thu hút PR spam chất lượng thấp vì incentive là số lượng. Nhiều project đã opt-out hoặc strict về quality. Nếu tham gia, ưu tiên quality PR thay vì rush 4 PR bằng mọi giá — PR spam tệ hơn không có PR.

Google Summer of Code (GSoC)

Program 3 tháng có trả thù lao (~3,000–6,600 USD tùy khu vực), làm việc cùng mentor từ OSS organization. Yêu cầu có contribution trước vào project (thường 1–3 PR merged) để qualify proposal. Deadline application thường tháng 3–4.

Một số AI/ML org thường participate: NumPy, scikit-learn, OpenCV, Astropy, Matplotlib.

Outreachy

Program tương tự GSoC, focus vào người thuộc underrepresented group trong tech. Trả thù lao 7,000 USD cho 13 tuần. Không yêu cầu bằng CS — trái ngành được welcome.

Thông tin tại outreachy.org. Đợt apply tháng 1 và tháng 8.

Có PR merged rồi — cần đặt đúng chỗ để người đọc thấy:

GitHub profile README

## Open Source Contributions

- [scikit-learn #12345](https://github.com/scikit-learn/scikit-learn/pull/12345)
  — Added type hints to `sklearn.preprocessing.StandardScaler`
- [gradio #6789](https://github.com/gradio-app/gradio/pull/6789)
  — Fixed example in Blocks documentation

LinkedIn About section

Thêm vào đoạn đầu About: "Contributor to scikit-learn and Hugging Face datasets."

Không cần liệt kê dài — mục tiêu là keyword xuất hiện trong profile để recruiter tìm thấy.

CV — Section Open Source Contributions

OPEN SOURCE CONTRIBUTIONS
─────────────────────────
scikit-learn (github.com/scikit-learn/scikit-learn)
• Added type annotations for preprocessing module — PR #12345 (merged)

Hugging Face datasets (github.com/huggingface/datasets)
• Fixed dataset loading script for VnCoreNLP — PR #6789 (merged)

Đặt section này ngay sau Projects nếu contribution đủ nổi bật.

Metrics theo dõi

• PR opened / merged / in-review
• Issue triage đã comment hoặc close
• Code review cho PR của người khác (cũng có giá trị)
• GitHub profile tab "Pull Requests" — số liệu public

Time investment thực tế

OSS contribution là long game. Không sprint để đạt số trong thời gian ngắn rồi burnout. 1 PR/tháng chất lượng tốt hơn 5 PR/tháng bị reject hoặc bị silent.

Maintain relationship sau PR merged

• Follow changelog của project để biết khi có regression liên quan đến contribution của mình
• Engage trên GitHub Discussions, Discord, Slack của project khi có câu hỏi liên quan
• Báo bug khi gặp trong quá trình dùng tool — đây cũng là contribution

Không phải repo nào cũng đáng đầu tư thời gian:

• Repo inactive 6+ tháng không commit — PR sẽ không được review và stale
• Maintainer rude hoặc dismissive trong issue thread — không worth tương tác
• License AGPL — nhiều employer có policy không dùng AGPL; contribution vào AGPL project có thể tạo conflict nếu bạn dùng code đó ở nơi làm việc
• Project có "license conflict" với employer hiện tại — đọc employment contract trước khi contribute
• Issue đã fix nhưng không được close (stale) — tốn công duplicate

• ✅ Bắt đầu OSS sau khi có 2–3 capstone project và thành thạo Git/GitHub workflow
• ✅ Chọn repo qua checklist 8 tiêu chí, không chọn theo độ nổi tiếng
• ✅ PR đầu tiên: Tier 1 (doc/test), scope 1–3 giờ
• ✅ Luôn comment trong issue trước khi fork và code
• ✅ Đọc CONTRIBUTING.md trước bất kỳ thứ gì
• ✅ 1 PR = 1 logical change, test đi kèm, lint pass trước push
• ✅ Phản hồi review trong 24–48h, không argue về style
• ✅ Showcase trên GitHub README, LinkedIn About, CV section riêng
• ✅ Domain crossover là lợi thế — contribute project trong ngành cũ

Bài 25: Pull Request đầu tiên cho project lớn — quy trình và etiquette