Đóng góp cho dự án AI mã nguồn mở: bắt đầu từ đâu

Bài này dựa trên GitHub Docs, bộ Open Source Guides (do GitHub cùng cộng đồng viết) và tệp CONTRIBUTING.md của huggingface/transformers, đọc ngày 11/11/2026. Bạn cần biết issue và pull request trước; nếu chưa, đọc bài issue và pull request.

Vì sao nên đóng góp

Với sinh viên học AI, một đóng góp được gộp vào dự án thật cho thấy những điều mà bài tập ở trường khó chứng minh: bạn đọc được code lớn của người khác, làm theo quy trình của một nhóm, và nhận góp ý từ người có kinh nghiệm. Nó cũng là một mục rất tốt trong portfolio trên GitHub.

Đóng góp không chỉ là code. Theo Open Source Guides, bạn có thể viết hay sửa tài liệu, viết hướng dẫn, dịch, trả lời câu hỏi của người dùng khác, phân loại issue (tìm issue trùng, tái hiện lỗi), review code. Hướng dẫn nhấn mạnh rằng bạn không bắt buộc phải đóng góp code, và các mảng ngoài code thường là nơi dự án thiếu người nhất.

Bước 1: chọn dự án

Cách tìm dự án theo GitHub Docs:

• Xem trang chủ đề github.com/topics/<chủ-đề>, ví dụ machine-learning, nlp, computer-vision.
• Xem trang Trending và trang Explore (gợi ý theo hoạt động của bạn).
• Tìm issue gắn nhãn good first issue hoặc help wanted; GitHub Docs nói nhiều dự án dùng hai nhãn này cho việc hợp với người mới.

Bài tìm repo AI hay có thêm bộ lọc tìm kiếm như good-first-issues:>2.

Trước khi chọn, Open Source Guides gợi ý xem dự án có còn sống và có đón người mới không: commit gần nhất khi nào, bao nhiêu người đóng góp, issue có được trả lời không, pull request có được review và gộp trong thời gian hợp lý không, và người duy trì có thái độ thân thiện không.

Bước 2: đọc tệp hướng dẫn

Open Source Guides liệt kê các tệp ở thư mục gốc cần đọc:

• LICENSE: điều khoản dùng code. Hướng dẫn nói dự án không có giấy phép thì không phải mã nguồn mở. Xem bài đọc README và LICENSE.
• README: dự án làm gì, bắt đầu thế nào.
• CONTRIBUTING: dự án cần loại đóng góp nào và quy trình ra sao. Có tệp này là dấu hiệu dự án chào đón người đóng góp.
• CODE_OF_CONDUCT: quy tắc ứng xử trong cộng đồng.

Một số dự án còn yêu cầu ký thỏa thuận cấp phép cho người đóng góp (CLA) trước khi gộp; CONTRIBUTING sẽ ghi nếu có.

Ví dụ thật: luật đóng góp của transformers

Đọc CONTRIBUTING quan trọng vì mỗi dự án một luật. Tệp CONTRIBUTING.md của huggingface/transformers (đọc ngày 11/11/2026) có những quy định rất cụ thể:

• Có hai cách mở PR: sửa một issue đang mở cho đóng góp, hoặc mở PR độc lập kèm bằng chứng.
• Được làm các issue gắn nhãn contributions-welcome, New model, hoặc issue chính bạn mở sau khi người duy trì gắn nhãn triaged. Issue của người khác không mở cho PR nếu người duy trì chưa cho phép; PR gắn với issue không được phép sẽ bị đóng.
• Không cần hỏi trước với issue đủ điều kiện, dự án không giao issue cho ai; bình luận kiểu "cho tôi làm được không" bị coi là gây nhiễu. PR đầu tiên cho một issue được ưu tiên.
• PR sửa lỗi cần một đoạn script ngắn chạy lỗi trên nhánh main và chạy đúng với bản sửa. PR tăng tốc cần số đo trước và sau trên khối lượng việc thực tế, kèm phần cứng.
• Một lỗi chính tả đơn lẻ là quá nhỏ cho một PR; sửa hàng loạt chữ trong tài liệu cần mở issue trước.
• Cách bạn viết code là việc của bạn, nhưng bạn chịu trách nhiệm cho mọi thứ mình gửi, và dự án có thể chặn tài khoản liên tục gửi issue hay PR kém chất lượng.

Lưu ý điểm thứ ba: nhiều dự án khác lại muốn bạn bình luận nhận việc trước để tránh làm trùng. Không có luật chung, chỉ có CONTRIBUTING của từng dự án.

Soát nhanh một dự án bằng Python

Đoạn code dưới đây gọi API công khai của GitHub để soát một kho trước khi bạn bỏ công: kho có đủ README, LICENSE, CONTRIBUTING, quy tắc ứng xử và mẫu pull request không (qua đường dẫn community/profile), lần push gần nhất cách đây bao lâu, có bị lưu trữ không, và có bao nhiêu issue đang mở theo các nhãn bạn đưa vào.

"""Soát một kho GitHub trước khi đóng góp: có đủ tệp hướng dẫn không, còn hoạt động không, có issue cho người mới không.

Dùng API công khai của GitHub (không cần khóa, không đăng nhập thì giới hạn số lần gọi):
- GET /repos/{kho}/community/profile: README, LICENSE, CONTRIBUTING, quy tắc ứng xử, mẫu issue, mẫu PR;
- GET /repos/{kho}: ngày push gần nhất, đã lưu trữ chưa;
- GET /search/issues?q=repo:{kho} label:"..." state:open is:issue: số issue mở theo nhãn.
Chạy không tham số: dùng dữ liệu mẫu chụp ngày 11/11/2026. Chạy với --that chu/kho [nhãn ...]: gọi API thật.
"""
import json
import sys
import urllib.parse
import urllib.request
from datetime import date

API = "https://api.github.com"
# Không xét issue_template: theo thử nghiệm ngày 11/11/2026, API trả rỗng cả với kho dùng mẫu dạng biểu mẫu (issue forms).
TEP_CAN = ["readme", "license", "contributing", "code_of_conduct", "pull_request_template"]


def danh_gia(ten, ho_so, kho, so_issue, hom_nay):
    dong = [f"== {ten}"]
    co = {k: v is not None for k, v in ho_so["files"].items()}
    thieu = [k for k in TEP_CAN if not co.get(k)]
    dong.append("  tệp hướng dẫn: " + ("đủ" if not thieu else "thiếu " + ", ".join(thieu)))
    so_ngay = (hom_nay - date.fromisoformat(kho["pushed_at"][:10])).days
    if kho.get("archived"):
        dong.append("  đã lưu trữ: không nhận đóng góp")
    else:
        dong.append(f"  lần push gần nhất: {so_ngay} ngày trước" + (" (lâu, cân nhắc)" if so_ngay > 90 else ""))
    for nhan, so in so_issue.items():
        dong.append(f"  issue mở nhãn '{nhan}': {so}")
    if not any(so_issue.values()):
        dong.append("  không có issue mở theo các nhãn này: đọc CONTRIBUTING xem dự án dùng nhãn nào")
    return dong


MAU = {
    "scikit-learn/scikit-learn": (
        {"files": {"readme": {}, "license": {}, "contributing": {}, "code_of_conduct": {},
                   "issue_template": None, "pull_request_template": {}}},
        {"pushed_at": "2026-11-11T00:00:00Z", "archived": False},
        {"good first issue": 0, "help wanted": 171},
    ),
    "huggingface/transformers": (
        {"files": {"readme": {}, "license": {}, "contributing": {}, "code_of_conduct": {},
                   "issue_template": None, "pull_request_template": {}}},
        {"pushed_at": "2026-11-11T00:00:00Z", "archived": False},
        {"contributions-welcome": 4},
    ),
}


def chay_thu():
    dong = []
    for ten, (ho_so, kho, so_issue) in MAU.items():
        dong += danh_gia(ten, ho_so, kho, so_issue, date(2026, 11, 11))
    print("\n".join(dong))
    return dong


def goi(duong):
    yc = urllib.request.Request(API + duong, headers={"Accept": "application/vnd.github+json"})
    with urllib.request.urlopen(yc, timeout=20) as phan_hoi:
        return json.load(phan_hoi)


def chay_that(ten, cac_nhan):
    so_issue = {}
    for nhan in cac_nhan:
        q = f'repo:{ten} label:"{nhan}" state:open is:issue'
        so_issue[nhan] = goi("/search/issues?" + urllib.parse.urlencode({"q": q, "per_page": 1}))["total_count"]
    print("\n".join(danh_gia(ten, goi(f"/repos/{ten}/community/profile"), goi(f"/repos/{ten}"), so_issue,
                             date.today())))


if __name__ == "__main__":
    if len(sys.argv) > 2 and sys.argv[1] == "--that":
        chay_that(sys.argv[2], sys.argv[3:] or ["good first issue", "help wanted"])
    else:
        chay_thu()

Dữ liệu mẫu chụp ngày 11/11/2026 cho thấy đúng điều cần nhớ về nhãn: scikit-learn có 0 issue mở gắn good first issue nhưng 171 issue gắn help wanted; transformers có 4 issue gắn contributions-welcome. Nếu chỉ tìm theo good first issue, bạn sẽ tưởng scikit-learn không cần người. Khi một nhãn cho kết quả 0, đọc CONTRIBUTING xem dự án dùng nhãn nào. Lúc thử, API trả trống trường mẫu issue cả với kho có biểu mẫu issue, nên đoạn code không xét trường này.

Bước 3: làm thay đổi nhỏ, có bằng chứng

Fork kho, clone bản fork, tạo nhánh mới cho đúng một việc. Trước khi sửa, chạy được bộ test của dự án trên máy (CONTRIBUTING thường có hướng dẫn cài môi trường phát triển). Vài kiểu đóng góp đầu tiên hợp với người học AI:

• Sửa ví dụ trong tài liệu bị lỗi: chạy thử ví dụ, thấy lỗi, sửa và ghi rõ đã chạy thế nào.
• Báo lỗi có kịch bản tái hiện: một đoạn script ngắn, dùng mô hình hay cấu hình công khai, chạy ra lỗi trên bản mới nhất.
• Thêm test cho trường hợp chưa được kiểm.
• Dịch hoặc viết hướng dẫn nếu dự án có mục dịch.

Giữ thay đổi nhỏ và đúng phạm vi issue. Đừng tiện tay định dạng lại cả tệp hay đổi tên biến không liên quan; người review sẽ phải đọc cả những dòng đó.

Bước 4: gửi pull request và trả lời review

Mô tả PR nói rõ đổi gì, vì sao, đã kiểm thế nào, và nối với issue bằng từ khóa như Fixes #123 để issue tự đóng khi PR được gộp. Open Source Guides khuyên với thay đổi lớn thì mở issue hỏi trước, còn có thể mở PR sớm ở dạng nháp để nhận góp ý.

Khi có review, trả lời từng góp ý, sửa trên cùng nhánh rồi push. Người duy trì là người làm tình nguyện hoặc có rất nhiều việc; PR của bạn có thể chờ nhiều ngày. Tôn trọng quyết định của họ, kể cả khi PR không được gộp.

Dùng AI khi đóng góp

Trợ lý AI giúp bạn đọc nhanh một codebase lạ, giải thích một hàm, gợi ý cách sửa. Nhưng như CONTRIBUTING của transformers ghi, bạn chịu trách nhiệm cho mọi thứ mình gửi. Vài nguyên tắc:

• Hiểu và tự chạy được mọi dòng trong PR; trả lời được câu hỏi của người review mà không phải hỏi lại AI.
• Đừng để AI viết hàng loạt PR hay bình luận chung chung; nhiều dự án coi đó là gây nhiễu và có thể chặn tài khoản.
• Kiểm kết quả AI làm như bài kiểm chứng việc AI làm.
• Nếu CONTRIBUTING có quy định về nội dung do AI tạo ra, làm đúng quy định đó.

Câu hỏi thường gặp

Học tiếp

• Ôn lại quy trình issue, nhánh, PR: issue và pull request.
• Tìm dự án phù hợp: tìm repo AI hay.
• Đưa đóng góp vào hồ sơ: portfolio AI trên GitHub.
• Xem lại toàn bộ chủ đề: GitHub cho người học AI.

Nếu bạn muốn học Python và AI bài bản cùng giảng viên, tham khảo khóa học AI của Big-O Coding.

Nguồn tham khảo

• GitHub Docs: Finding ways to contribute to open source on GitHub
• Open Source Guides: How to Contribute to Open Source
• huggingface/transformers: CONTRIBUTING.md
• GitHub Docs: REST API endpoints for community metrics