Đóng góp mã nguồn mở thời AI mà không làm phiền người duy trì: kế hoạch bốn tuần

Dành cho bất kỳ ai muốn thử đóng góp cho một dự án mã nguồn mở, kể cả người mới và người dùng AI nhiều. Không cần biết trước quy trình của cộng đồng. Thuật ngữ nào cũng đi kèm một ví dụ đời thường, và phần ví dụ git được đánh dấu để bỏ qua nếu bạn chưa cần.

Số liệu lấy từ nguồn công khai, có liệt kê cuối bài. Ví dụ ghi là "minh họa" được dựng lại, không nhắc đến người hay dự án thật. Bài không kể trải nghiệm đóng góp cá nhân của tôi, vì tôi không có trải nghiệm đó để kể. Phần ví dụ git được tôi chạy thật trên một kho thử trên máy. Cách các mô hình AI hoạt động bên trong chưa ai hiểu hết, nên các hình dung dưới đây chỉ là cách tưởng tượng để dễ nhớ.

---

Tóm tắt nhanh#

• Người duy trì (maintainer) dự án mã nguồn mở đang nhận nhiều đóng góp kém chất lượng do AI sinh ra. Khảo sát của Linux Foundation Research (20/10/2026) ghi nhận người duy trì ước tính khoảng 25% pull request là "rác AI" (AI slop), và 31% ở dự án lớn.
• Một ví dụ cụ thể: dự án curl dừng chương trình thưởng lỗi từ cuối tháng 1/2026. Người duy trì chính cho biết tỷ lệ báo cáo lỗi bảo mật có thật rơi từ trên 15% xuống dưới 5%.
• Cách làm không làm phiền họ nằm trong bốn tuần: tuần 1 đọc và dùng dự án, tuần 2 chọn một việc nhỏ đã được chấp nhận và hỏi trước, tuần 3 làm một thay đổi nhỏ có test mà bạn tự giải thích được không cần AI, tuần 4 mở pull request rõ ràng, khai báo AI và nhận phản hồi bình tĩnh.
• Mỗi dự án có luật riêng và luật đổi nhanh. Có dự án cho dùng AI với điều kiện khai báo và hiểu, có dự án cấm hẳn. Bạn phải đọc luật của đúng dự án đó, không dựa vào bài này.
• Trong ví dụ git chạy thật của bài (Git 2.56.0), một thay đổi nhỏ đi qua ba bước: test trước, sửa sau, rồi sửa lại theo phản hồi. Lần chạy đầu của tôi còn báo "NO TESTS RAN", một lý do để luôn ghi số test đã chạy.
• Bị từ chối là chuyện thường. Mục tiêu bốn tuần không phải là được merge bằng mọi giá, mà là làm đúng cách để lần sau có người muốn đọc bài của bạn.

---

Từ khó, nói dễ#

---

Sau bài này bạn giải thích được#

1. Vì sao người duy trì dự án mã nguồn mở khó chịu với đóng góp do AI sinh, và chính sách của họ có thể khác nhau hoàn toàn.
2. Thứ tự bốn tuần: đọc luật, hỏi trước, sửa nhỏ có test và hiểu từng dòng, rồi mới mở PR và khai báo AI.
3. Cách dùng git cho luồng này: nhánh riêng, commit có test, rebase khi dự án đã đi tiếp, sửa lại sau phản hồi.

---

1. Hình dung trước: bạn là khách trong xưởng của người khác#

Hình dung một xưởng mộc nhỏ do một người chủ trông coi, mở cửa cho khách ghé thăm. Một vị khách bước vào và nói: "Tôi thấy chỗ này có thể làm đẹp hơn", rồi mang theo một xe đồ tự làm, tự đặt vào ba bốn góc xưởng. Có thể đồ tốt. Nhưng chủ xưởng phải xem từng món, dọn chỗ, và nếu hỏng thì ông phải chịu. Một vị khách khác đến, ngồi xem một tuần, hỏi: "Tôi giúp mài giùm cái ghế này được không?", rồi mài đúng một cái ghế và đưa ra xem. Chủ xưởng sẽ nhớ cái tên thứ hai.

Mã nguồn mở cũng vậy. Người duy trì thường là người làm việc ngoài giờ hoặc không lương. Mỗi pull request là một món đồ họ phải kiểm. AI làm cho việc gửi món đồ rẻ đi rất nhiều, nhưng việc kiểm thì vẫn tốn thời gian của người duy trì.

Điều rút ra: việc đóng góp tốt không đo bằng số dòng bạn gửi mà bằng mức độ bạn làm cho người duy trì dễ nói đồng ý.

---

2. Vì sao người duy trì đang quá tải#

2.1 Khảo sát của Linux Foundation Research (20/10/2026)#

Linux Foundation Research công bố báo cáo "Navigating Open Source Software Development in the Generative AI Era: Challenges and Opportunities for Project Communities" ngày 20/10/2026. Theo thông cáo của họ, người duy trì ước tính khoảng 25% pull request đến là rác do AI sinh, và 31% ở các dự án lớn. Cũng theo thông cáo: 59% người duy trì thấy lượng đóng góp tăng (69% ở dự án lớn), khoảng 35% dự án có chính sách chính thức cho phép dùng AI, 32% chưa có chính sách và chưa định có, và 61% người đóng góp nói họ xem xét kỹ và kiểm thử đầy đủ code do AI sinh trước khi gửi. Thông cáo cũng ghi người trả lời ước tính AI giảm trung bình khoảng 52% thời gian viết code.

Cần đọc cho đúng. Đây là ước tính của người trả lời khảo sát, không phải số đếm pull request. Số người trả lời không được nêu trong thông cáo tôi đọc. Tôi chỉ đọc thông cáo, chưa đọc cả báo cáo. Mẫu có thể thiên về những người chịu trả lời khảo sát.

Điều rút ra: vấn đề có thật và được đo, nhưng phần lớn dự án chưa có luật rõ. Bạn phải tự đi tìm luật.

2.2 Một dự án làm ví dụ: curl dừng chương trình thưởng lỗi#

Daniel Stenberg, người duy trì chính của curl, viết trong bài "The end of the curl bug-bounty" ngày 26/1/2026 rằng curl không còn chương trình thưởng lỗi, chương trình dừng từ 31/1/2026. Ông nêu rằng trước năm 2025, tỷ lệ báo cáo được xác nhận là lỗ hổng thật là "trên 15%", và từ 2025 là "dưới 5%", tức không tới một trên hai mươi báo cáo là thật. Ông cho rằng lý do gồm báo cáo rác do AI sinh, báo cáo kém chất lượng do người viết, và thái độ thiếu thiện chí của một số người, và ông ngờ rằng phần thưởng tiền mặt đã thu hút kiểu lạm dụng đó. Ông cũng nói người gửi báo cáo rác do AI tiếp tục bị cấm.

Điều này mô tả một dự án và là quan sát của người trong cuộc. Nó không chứng minh mọi dự án đều như vậy, và phần thưởng tiền có thể là yếu tố riêng của curl.

Điều rút ra: khi người nhận bị ngập, họ rút bớt cửa. Cửa đóng lại thì cả người đóng góp tốt cũng chịu.

2.3 GitHub cho người duy trì thêm công cụ#

Ngày 13/2/2026 GitHub thêm hai cài đặt cho kho mã: tắt hẳn pull request, hoặc chỉ cho người có quyền ghi mở pull request mới (mọi người vẫn đọc và bình luận được). Hai cài đặt nằm ở Settings, General, Features. Theo một bài blog Nhật mà tôi tìm thấy, có người thử và thấy cài đặt "chỉ người cộng tác" chưa hoạt động đúng như mô tả vào thời điểm đó, nên hãy coi đây là thông tin có thể đã thay đổi. GitHub cũng được tin là đã thêm giới hạn số pull request mở cùng lúc cho người không có quyền ghi (tháng 6/2026, tôi chỉ thấy qua bài tin).

Điều rút ra: một số kho sẽ không nhận pull request từ người lạ. Việc đầu tiên là biết kho đó có nhận không.

2.4 Một chính sách thật: Ghostty#

Để thấy chính sách cụ thể có thể nghiêm đến đâu, tôi đọc tệp CONTRIBUTING.md và tệp AI_POLICY.md của dự án Ghostty. Tôi chỉ nêu điều đọc được ở thời điểm đọc, và chính sách có thể đã đổi khi bạn đọc bài. Theo hai tệp đó: dự án cho phép dùng AI để viết code, nhưng yêu cầu khai báo mọi việc dùng AI (nêu công cụ và mức độ), yêu cầu người đóng góp hiểu toàn bộ code mình gửi và giải thích được nó mà không cần AI, và người lần đầu đóng góp phải được "vouch" (bảo lãnh) trước, nếu không pull request sẽ bị tự động đóng. Dự án cũng có danh sách công khai những người bị từ chối vì gửi đóng góp rác. Chính sách này chỉ áp cho người ngoài, không áp cho người duy trì.

Đây chỉ là một dự án. Dự án khác có thể cho tự do hơn, hoặc cấm hẳn đóng góp do AI sinh. Bài này không dựa vào dự án nào ngoài ví dụ đã đọc ở trên.

Điều rút ra: luật của dự án nằm ở chính dự án. Câu hỏi đầu tiên không phải "làm gì" mà là "ở đây họ quy định thế nào".

---

3. Kế hoạch bốn tuần#

Hình dung bốn lần ghé xưởng: lần một đi xem, lần hai hỏi, lần ba làm, lần bốn đưa ra. Thời gian dưới đây là gợi ý, khoảng vài giờ mỗi tuần.

Tuần 1. Đọc và dùng dự án#

Việc làm:

1. Chọn một dự án bạn đang dùng thật. Dự án bạn chưa dùng thì bạn khó biết thế nào là hữu ích.
2. Đọc README, CONTRIBUTING, CODE_OF_CONDUCT và, nếu có, chính sách về AI. Tìm xem dự án có nhận pull request từ người lạ không.
3. Đọc khoảng năm pull request đã được nhận và năm pull request bị đóng. Chú ý cách người ta viết mô tả và lý do bị đóng.
4. Cài và chạy dự án trên máy, chạy bộ test của dự án một lần.

Mang đi: năm dòng "luật chơi của dự án này" do bạn tự viết, kèm lệnh chạy test.

Tuần 2. Chọn một việc nhỏ đã được chấp nhận và hỏi trước#

Việc làm:

1. Tìm issue có nhãn gợi ý cho người mới (ví dụ good first issue) và chưa ai nhận.
2. Đọc kỹ issue và các bình luận. Một issue được người duy trì xác nhận mới đáng làm.
3. Bình luận xin nhận việc, nêu cách bạn dự định làm trong hai ba câu, và chờ phản hồi trước khi viết code.
4. Nếu chờ nhiều ngày mà chưa ai trả lời, đừng làm ngay một thay đổi lớn. Hỏi lại hoặc chọn việc khác.

Mang đi: một bình luận ngắn, lịch sự và rõ ràng, được người duy trì trả lời.

Tuần 3. Làm một thay đổi nhỏ có test và tự hiểu được#

Việc làm:

1. Tạo nhánh riêng. Viết một test thất bại để tái hiện vấn đề, rồi sửa cho test đạt.
2. Giữ một mục đích duy nhất. Không sửa thêm định dạng hay đổi tên hàng loạt trong cùng PR.
3. Chạy toàn bộ test của dự án và ghi số test đã chạy.
4. Dùng AI được nếu dự án cho phép, nhưng làm bài kiểm tra này: tắt AI và giải thích thành lời từng dòng bạn đổi, cho người khác hoặc cho chính bạn. Chỗ nào bạn không giải thích được thì bạn chưa hiểu, và chưa sẵn sàng gửi.

Mang đi: một nhánh với một commit sạch, có test chạy được.

Tuần 4. Mở PR rõ ràng, khai báo AI, nhận phản hồi bình tĩnh#

Việc làm:

1. Viết mô tả PR theo mẫu ở phần 5: vấn đề, cách sửa, cách kiểm, và dòng khai báo AI theo đúng yêu cầu của dự án.
2. Tự duyệt diff của chính mình trước khi gửi (xem Duyệt code do AI viết).
3. Khi nhận phản hồi, trả lời ngắn, sửa đúng điều được yêu cầu, và nếu dự án đã đi tiếp thì rebase.
4. Nếu bị từ chối, cảm ơn, hỏi lại nếu chưa rõ, và đừng tranh luận.

Mang đi: một PR mà người duy trì mở ra thấy ngay mục đích và cách kiểm.

---

4. Ví dụ chạy thật: luồng git của một đóng góp nhỏ (có thể bỏ qua nếu bạn chưa dùng git)#

Hình dung bạn tập trong một xưởng giả trước khi vào xưởng thật. Tôi dựng một "xưởng giả" ngay trên máy: một kho bare làm "kho gốc của dự án", và một bản sao làm "fork của bạn". Mọi lệnh dưới đây tôi đã chạy thật bằng Git 2.56.0 và Python 3.14.8. Hash commit sẽ khác trên máy bạn.

Lưu ý: đây không phải GitHub. Trên GitHub, bạn bấm Fork trên web, đẩy nhánh lên fork của mình rồi mở pull request trên web. Phần chung là các lệnh git: tạo nhánh, commit, rebase, sửa lại. Trong ví dụ, "dự án" là một thư viện nhỏ tên textkit có hàm slugify biến tiêu đề thành đoạn ngắn dùng trong địa chỉ web. "Vấn đề" là slugify("Hello World!") trả về hello-world- có dấu gạch thừa ở cuối.

4.1 Trước khi sửa: chạy test, tạo nhánh#

$ python3 -m unittest -q
Ran 1 test in 0.000s

OK

$ git switch -c fix-slug-trailing-dash

Một lần chạy đầu bị lỗi ngầm. Lần chạy đầu của tôi in ra "Ran 0 tests" và "NO TESTS RAN", vì thư mục tests thiếu tệp __init__.py nên bộ chạy test không tìm thấy gì. Không có dòng nào đỏ, chỉ không có test nào chạy. Đây đúng là lý do bài Làm cho kết quả của AI tự chứng minh khuyên luôn ghi số test đã chạy: "không có lỗi" chưa chắc là "đã kiểm".

4.2 Viết test thất bại trước#

Tôi thêm test cho ca có dấu chấm than và khoảng trắng ở hai đầu, rồi chạy khi chưa sửa:

$ python3 -m unittest -q
FAIL: test_no_trailing_dash (tests.test_slug.SlugTests.test_no_trailing_dash)
Traceback (most recent call last):
  File "tests/test_slug.py", line 10, in test_no_trailing_dash
    self.assertEqual(slugify("Hello World!"), "hello-world")
AssertionError: 'hello-world-' != 'hello-world'

Ran 2 tests in 0.000s

FAILED (failures=1)

Test thất bại đúng vì lý do mong đợi. Nếu test đạt ngay khi chưa sửa, hoặc thất bại vì lý do khác, test đang kiểm cái gì đó không phải vấn đề của bạn.

4.3 Sửa và chạy lại#

$ python3 -m unittest -q
Ran 2 tests in 0.000s

OK

$ git diff --stat
 tests/test_slug.py | 4 ++++
 textkit/slug.py    | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

Hai tệp, năm dòng thêm và một dòng đổi: đủ nhỏ để người duy trì xem trong vài phút.

4.4 Commit có mô tả rõ và dòng khai báo#

fix(slug): strip leading and trailing dashes

slugify("Hello World!") returned "hello-world-". Strip dashes at both
ends and add a test for punctuation and surrounding spaces.

AI assistance: used an AI tool to draft the test; I read and ran it.

Dòng cuối là cách một dự án có thể yêu cầu khai báo. Hãy dùng đúng cách của dự án bạn đóng góp, không phải mẫu này.

4.5 Dự án đã đi tiếp: fetch và rebase#

Trong lúc bạn làm, người duy trì đẩy thêm một commit lên nhánh chính. Bạn lấy về và dời thay đổi của mình lên trên bản mới nhất:

$ git fetch origin
$ git log --oneline --graph --all
* 4cbdd85 docs: add a line on review etiquette
| * 0606d8e fix(slug): strip leading and trailing dashes
|/
* 7835b68 chore: initial textkit

$ git rebase origin/main
Successfully rebased and updated refs/heads/fix-slug-trailing-dash.

$ git log --oneline --graph --all
* ea41359 fix(slug): strip leading and trailing dashes
* 4cbdd85 docs: add a line on review etiquette
| * 0606d8e fix(slug): strip leading and trailing dashes
|/
* 7835b68 chore: initial textkit

Cùng một thay đổi nhưng hash đổi (từ 0606d8e sang ea41359) vì nó nay nằm trên một nền mới. Commit cũ 0606d8e còn nằm ở nhánh đã đẩy lên trước đó.

4.6 Phản hồi từ người duyệt: sửa lại và đẩy bản mới#

Giả sử người duyệt xin thêm một test cho chuỗi rỗng. Tôi thêm test, chạy, rồi sửa lại commit cũ thay vì thêm commit chữa cháy:

$ python3 -m unittest -q
Ran 3 tests in 0.000s

OK

$ git commit --amend --no-edit
$ git push --force-with-lease origin fix-slug-trailing-dash
 + 0606d8e (cũ), d109624 (mới): nhánh fix-slug-trailing-dash (forced update)

$ git diff origin/main --stat
 tests/test_slug.py | 7 +++++++
 textkit/slug.py    | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

Git thật in một dòng nối hai hash cũ và mới bằng ký hiệu riêng; tôi viết lại cho dễ đọc, kết quả là hash 0606d8e được thay bằng d109624 trên máy chủ. --force-with-lease chỉ ghi đè khi nhánh trên máy chủ đúng như bạn nghĩ. Chỉ dùng nó trên nhánh của chính bạn (nhánh PR), tuyệt đối không dùng trên nhánh chính của dự án. Một số dự án muốn bạn thêm commit mới thay vì sửa lại, nên hãy xem hướng dẫn của dự án.

4.7 Một cách khác: tạo tệp vá#

Một số cộng đồng nhận thay đổi dưới dạng tệp vá gửi qua thư:

$ git format-patch -1 -o ../patches
../patches/0001-fix-slug-strip-leading-and-trailing-dashes.patch

Cách này ít gặp hơn trên GitHub nhưng vẫn dùng ở nhiều dự án lớn. Dự án nào dùng cách nào sẽ ghi trong CONTRIBUTING.

Ghi chú về ví dụ: đây là kho thử một người, không có người duyệt thật và không có giao diện web. Nó chứng minh các lệnh chạy được và cho ra kết quả như đã dán, không chứng minh một cuộc trao đổi thật diễn ra thế nào.

---

5. Mẫu mô tả PR và danh sách tự kiểm#

5.1 Mẫu mô tả pull request#

## Vấn đề
Một hai câu: cái gì sai, khi nào gặp. Dẫn tới issue (Closes #123).

## Cách sửa
Một hai câu: bạn đổi cái gì và vì sao chọn cách này.

## Cách kiểm
- Lệnh chạy test: python3 -m unittest
- Số test đã chạy: 3, tất cả đạt
- Test mới thất bại trước khi sửa: có

## Khai báo AI
Theo yêu cầu của dự án: có dùng AI không, công cụ nào, ở phần nào.
Tôi đã đọc, chạy và hiểu toàn bộ thay đổi.

5.2 Danh sách tự kiểm sáu câu trước khi bấm gửi#

1. Tôi có giải thích được từng dòng thay đổi mà không cần AI không?
2. Tôi đã chạy toàn bộ test của dự án và biết số test đã chạy chưa?
3. PR này có một mục đích duy nhất không?
4. Tôi đã đọc CONTRIBUTING và chính sách AI của dự án chưa, và làm đúng chưa?
5. Việc này đã được người duy trì chấp nhận trong issue chưa?
6. Mô tả có nói rõ cách kiểm để người duyệt làm theo được không?

Nếu có câu trả lời "không", hãy dừng và làm nốt trước khi gửi.

---

6. Lỗi hay gặp#

Hình dung vị khách trong xưởng: có những việc khách làm khiến chủ xưởng thở dài.

---

7. Minh họa: hai buổi sáng với cùng một issue#

Đây là tình huống minh họa, không nhắc đến người hay dự án thật. Hai người đóng góp cùng thấy một issue nhỏ.

Người thứ nhất không đọc luật:

• 09:00. Mở issue, thấy "việc dễ", nhờ AI sinh code.
• 09:40. AI sinh thay đổi 600 dòng, trong đó có định dạng lại ba tệp và một đoạn tối ưu thêm. Người đóng góp chưa đọc hết, mở PR, không có dòng khai báo AI.
• 14:00. Người duy trì đóng PR kèm lời nhắc đọc CONTRIBUTING: việc này chưa được chấp nhận và quá lớn. Người đóng góp mất một buổi sáng và không biết sai ở đâu.

Người thứ hai theo kế hoạch bốn tuần:

• 09:00. Đọc CONTRIBUTING, thấy dự án yêu cầu khai báo AI và hỏi trước khi làm.
• 09:20. Bình luận xin nhận việc, nêu cách sửa trong hai câu.
• Hôm sau, 10:00. Người duy trì trả lời "Ổn, cứ làm".
• Hôm sau, 15:00. Viết test thất bại trước, sửa, chạy toàn bộ test, đọc lại từng dòng không cần AI, rồi mở PR chỉ thêm khoảng 8 dòng, có dòng khai báo.
• Ngày thứ ba, 09:00. Người duyệt xin thêm một test, người đóng góp sửa lại trong 15 phút.

Việc nên làm: chặn mình ở bước hỏi trước và bước tự giải thích. Hai bước này tốn khoảng nửa giờ, nhưng thường tiết kiệm cho cả hai phía cả buổi sáng.

Minh họa này không thay cho bằng chứng. Bằng chứng nằm ở khảo sát của Linux Foundation và trường hợp curl ở phần 2: người duy trì thật đang chịu tải lớn và đang đóng cửa, nên một đóng góp dễ duyệt là món quà thật. Hai nguồn này là ước tính và kể lại của người trong cuộc, không phải thí nghiệm đối chứng.

---

8. Bài tập có đáp án#

Bài tập A. Tìm lỗi trong mô tả PR#

Mô tả sau là của một PR: "Fix stuff. Đã sửa lỗi, dùng AI cho nhanh. Đổi luôn định dạng toàn bộ thư mục. Đã test."

Tìm ít nhất năm điểm yếu.

Đáp án: (1) không nói vấn đề cụ thể và không dẫn tới issue; (2) "dùng AI cho nhanh" chưa nêu công cụ, phần nào, cũng chưa nói đã đọc và hiểu; (3) đổi định dạng toàn thư mục là một mục đích thứ hai, tách riêng; (4) "đã test" không nêu lệnh, số test, hay test mới có thất bại trước khi sửa không; (5) không có cách để người duyệt tự kiểm; (6) tiêu đề "Fix stuff" không nói gì.

Bài tập B. Hỏi trước hay làm ngay?#

Trong kho thử, slugify("Xin chào") trả về xin-ch-o (tôi đã chạy thật). Bạn thấy chữ có dấu bị mất. Bạn nên mở PR sửa ngay hay bình luận hỏi trước?

Đáp án: nên hỏi trước. Cách xử lý chữ có dấu là một quyết định thiết kế: bỏ dấu (xin-chao), giữ nguyên, hay chuyển ký tự. Người duy trì có thể có lý do giữ hành vi hiện tại hoặc muốn một cách khác. Mở PR ngay có thể bị đóng dù code của bạn chạy đúng. Bình luận hai ba câu nêu hiện tượng, vài lựa chọn và hỏi họ muốn hướng nào là đủ.

Bài tập C. Test đạt ngay khi chưa sửa#

Bạn thêm test slugify("Hello---World") == "hello-world". Chạy ngay thì đạt trước khi sửa gì (tôi đã chạy thật). Bạn nên làm gì?

Đáp án: đây không phải lỗi. Hàm đã gom các dấu gạch liên tiếp thành một. Một test đạt sẵn có thể vẫn đáng thêm như bảo vệ hành vi hiện có, nhưng không phải là bằng chứng bạn đã sửa lỗi, và không nên đóng gói như một "bản sửa". Hãy xem lại vấn đề thật là gì.

---

9. Nhìn cân bằng: biết gì, chưa biết gì#

Khá chắc: người duy trì báo cáo lượng đóng góp tăng và một phần đáng kể chất lượng thấp; ít nhất một dự án lớn (curl) đã đóng một cửa vì lý do này; một số dự án (như Ghostty) có chính sách rõ về AI.

Chưa rõ hoặc đáng thận trọng:

• Con số 25% và 31% là ước tính của người trả lời khảo sát, không phải số đếm. Tôi chưa đọc toàn bộ báo cáo.
• Trường hợp curl là một dự án, một người trong cuộc, và phần thưởng tiền có thể làm nó khác các dự án không có thưởng.
• Chính sách đổi nhanh. Bài này chỉ nêu những gì tôi đọc được ở thời điểm đọc.
• Tôi chưa thấy nghiên cứu đo trực tiếp việc làm theo kế hoạch bốn tuần có tăng tỷ lệ được merge không. Kế hoạch là tổng hợp thực hành, không phải kết quả thí nghiệm.

Đừng thổi phồng. Không có cách nào đảm bảo PR của bạn được nhận. Dự án có thể từ chối vì lý do chẳng liên quan đến bạn: đang đóng băng phát hành, đổi hướng, hoặc đơn giản là hết sức.

Đừng coi nhẹ. Có dự án cấm hẳn đóng góp do AI sinh. Khi gặp, hãy làm theo, không thử lách.

---

10. Kết luận#

Đóng góp mã nguồn mở thời AI là một việc của sự tôn trọng: đọc luật trước, hỏi trước, gửi ít và dễ duyệt, và tự hiểu thứ mình gửi. AI giúp bạn viết nhanh hơn, nhưng cũng giúp bạn gửi thứ chưa hiểu nhanh hơn. Bốn tuần ở trên là cách đặt các điểm dừng vào đúng chỗ.

Nếu bạn muốn thực hành luồng git này, hãy làm trong một kho thử trước. Xem thêm Git cho người dùng agent cho các lệnh cứu hộ, Gỡ lỗi như thám tử để tái hiện lỗi trước khi sửa, và Học một thư viện lạ cùng AI mà không mất tay nghề cho cách học một dự án mới mà vẫn giữ tay nghề.

---

Nguồn tham khảo#

Số liệu lấy từ nguồn công khai tính đến tháng 10/2026. Chính sách của từng dự án có thể đã thay đổi, nên hãy mở nguồn gốc để kiểm tra trước khi làm theo.

• Linux Foundation, thông cáo về khảo sát "Navigating Open Source Software Development in the Generative AI Era" (20/10/2026) và bản tin tóm tắt
• Daniel Stenberg, The end of the curl bug-bounty (26/1/2026)
• GitHub Changelog, New repository settings for configuring pull request access (13/2/2026)
• Ghostty, CONTRIBUTING.md và AI_POLICY.md (đọc tháng 10/2026, chính sách có thể đã đổi)
• Git, tài liệu git-rebase, git-push (--force-with-lease) và git-format-patch