Người mới có thể bắt đầu đóng góp cho một dự án mã nguồn mở xử lý tiếng Việt mà chưa cần viết thuật toán nào: báo lỗi kèm ví dụ tái hiện được, sửa và bổ sung tài liệu, thêm ca kiểm thử cho các trường hợp chữ Việt khó (dấu tổ hợp, kiểu đặt dấu cũ, không dấu, chữ hoa), trả lời câu hỏi của người dùng khác, rồi mới đến sửa lỗi nhỏ có gắn nhãn dành cho người mới. Mỗi bước đều cần đọc quy ước đóng góp của dự án trước.
Cộng đồng xử lý tiếng Việt nhỏ hơn nhiều so với cộng đồng tiếng Anh, nên nhiều thư viện tiếng Việt chỉ do một vài người duy trì lúc rảnh. Một báo lỗi rõ ràng hay một ca kiểm thử tốt có giá trị với họ hơn bạn nghĩ. Bài này đi qua từng loại đóng góp, cách làm sao cho được đón nhận, và những điều nên tránh để không thành gánh nặng cho người duy trì.
Vì sao đóng góp cho thư viện tiếng Việt đáng làm
Các thư viện xử lý tiếng Việt mã nguồn mở như VnCoreNLP hay underthesea, cùng nhiều công cụ nhỏ hơn cho tách từ, chuẩn hoá văn bản, phục hồi dấu, đọc số thành chữ, được dùng trong rất nhiều dự án học tập và sản phẩm. Bài này nhắc tên chỉ làm ví dụ cho loại dự án, không đánh giá dự án nào tốt hơn. Phần lớn những thư viện này không có đội ngũ toàn thời gian. Khi một lỗi tồn tại lâu, nó lặp lại trong hàng trăm dự án phía sau.
Với cá nhân người đóng góp, lợi ích cũng cụ thể. Bạn học cách đọc mã của người khác, viết kiểm thử, làm việc theo quy trình xem xét mã, những kỹ năng ít khi học được ở trường. Lịch sử đóng góp công khai là bằng chứng năng lực rõ ràng hơn một dòng "có kiến thức xử lý ngôn ngữ" trong hồ sơ. Và vì bạn là người bản ngữ, bạn nhận ra những lỗi tiếng Việt mà người duy trì có thể bỏ sót khi chỉ nhìn số liệu.
Quan trọng nhất, đây là cách thiết thực để tham gia cộng đồng AI Việt mà không cần là nhà nghiên cứu. Nhiều người duy trì dự án hiện nay bắt đầu bằng một báo lỗi nhỏ nhiều năm trước.
Báo một lỗi sao cho người duy trì sửa được
Báo lỗi là đóng góp dễ nhất và cũng hay bị làm kém nhất. Một báo lỗi tốt tiết kiệm cho người duy trì hàng giờ đoán mò.
- Tìm trong danh sách báo lỗi cũ, kể cả đã đóng, xem có ai báo chưa. Nếu có, bổ sung thông tin vào đó thay vì mở mới.
- Ghi rõ phiên bản thư viện, phiên bản ngôn ngữ lập trình, hệ điều hành.
- Đưa ví dụ tái hiện ngắn nhất có thể: một đoạn văn bản đầu vào, lệnh gọi, kết quả nhận được và kết quả mong đợi. Với tiếng Việt, ghi rõ văn bản có dùng ký tự tổ hợp không; lỗi do Unicode thường biến mất khi dán qua trình duyệt nên đính kèm tệp hoặc mã điểm ký tự.
- Mô tả vì sao bạn cho đó là lỗi theo quy ước của chính dự án. Ví dụ, nếu dự án tách "hoa hồng" thành một từ theo quy ước kho ngữ liệu nó dùng, đó không phải lỗi dù bạn nghĩ khác.
- Không dán dữ liệu thật có thông tin cá nhân của khách hàng hay người dùng. Tự viết câu ví dụ có cùng cấu trúc.
- Giữ giọng lịch sự, không thúc giục. Người duy trì không nợ bạn bản sửa.
Một báo lỗi kiểu "không chạy được, giúp với" kèm ảnh chụp màn hình mờ gần như chắc chắn bị bỏ qua. Ngược lại, báo lỗi có ví dụ tái hiện năm dòng thường được trả lời nhanh, kể cả khi người duy trì rất bận.
Tài liệu và ca kiểm thử: hai chỗ người bản ngữ góp được nhiều nhất
Sửa tài liệu. Hướng dẫn cài đặt lỗi thời, ví dụ không chạy với phiên bản mới, thiếu giải thích các tham số: đây là những thứ người mới nhận ra trước người duy trì, vì người duy trì đã quen. Sửa một hướng dẫn cài đặt sai là đóng góp nhỏ nhưng giúp mọi người đến sau.
Viết tài liệu tiếng Việt. Nhiều thư viện tiếng Việt viết tài liệu bằng tiếng Anh để tiếp cận quốc tế. Một bản hướng dẫn nhanh bằng tiếng Việt, đặt đúng chỗ dự án muốn, giúp sinh viên và người làm sản phẩm trong nước. Hỏi người duy trì trước xem họ muốn tổ chức tài liệu song ngữ thế nào.
Thêm ca kiểm thử chữ Việt khó. Bộ kiểm thử của nhiều dự án chỉ có câu "sạch". Bạn có thể thêm các ca: cùng một câu ở dạng dựng sẵn và tổ hợp, kiểu đặt dấu "hoà" và "hòa", câu không dấu, câu toàn chữ hoa, câu chêm tiếng Anh, số và ngày tháng, ký tự đặc biệt dán từ văn bản PDF. Mỗi ca kiểm thử ghi rõ kỳ vọng và lý do.
Thêm ví dụ thực tế. Một sổ ghi chép mẫu cho thấy cách dùng thư viện với một bài toán cụ thể, chẳng hạn chuẩn hoá bình luận trước khi phân loại, giúp người dùng mới hiểu nhanh hơn tài liệu tham chiếu khô khan.
Từ báo lỗi đến gửi mã sửa đầu tiên
Khi đã quen dự án, bước tiếp theo là sửa một lỗi nhỏ. Nhiều dự án gắn nhãn cho báo lỗi phù hợp người mới. Trước khi làm, để lại bình luận nói bạn muốn nhận việc đó và mô tả ngắn hướng sửa, để tránh hai người cùng làm và để người duy trì góp ý sớm nếu hướng của bạn không hợp.
Đọc kỹ tệp hướng dẫn đóng góp: quy ước đặt tên nhánh, định dạng mã, cách chạy kiểm thử, yêu cầu ký thoả thuận đóng góp nếu có. Giữ thay đổi nhỏ và tập trung: một yêu cầu gộp mã sửa đúng một vấn đề, kèm ca kiểm thử chứng minh lỗi đã hết. Một yêu cầu gộp sửa lỗi đồng thời định dạng lại cả tệp sẽ rất khó xem xét.
Khi được góp ý, coi đó là phần bình thường của quy trình chứ không phải chê bai. Người duy trì có thể yêu cầu sửa nhiều vòng vì họ phải chịu trách nhiệm lâu dài với mã. Nếu không đồng ý, giải thích lý do kỹ thuật một cách bình tĩnh; nếu họ vẫn quyết khác, tôn trọng quyết định đó, vì dự án là của họ.
Góp ý quy ước ngôn ngữ: khi cuộc tranh luận không nằm ở mã
Một phần đáng kể báo lỗi trong các thư viện tiếng Việt thật ra là tranh luận về quy ước: "hoà" hay "hòa", "kỹ" hay "kĩ", "quốc gia" có nên tách thành hai từ, "Nguyễn Văn" là một thực thể hay một phần của thực thể. Những câu hỏi này không có đáp án duy nhất; mỗi dự án chọn một quy ước theo kho ngữ liệu nó dựa vào hoặc theo nhu cầu người dùng. Đổi quy ước giữa chừng có thể làm hỏng hàng loạt dự án phía sau.
Nếu bạn muốn đề xuất thay đổi quy ước, cách được lắng nghe là đưa bằng chứng thay vì cảm nhận. Chỉ ra quy ước hiện tại gây lỗi gì cụ thể, ở loại văn bản nào, tần suất ra sao trên một mẫu bạn tự đo; dẫn các quy định chính tả hiện hành, như quy định dùng trong sách giáo khoa do Bộ Giáo dục và Đào tạo ban hành, hoặc công trình ngôn ngữ học có uy tín, khi liên quan. Đề xuất phương án chuyển đổi êm, ví dụ một tuỳ chọn cấu hình giữ hành vi cũ làm mặc định.
Người có nền ngôn ngữ học đóng góp được nhiều nhất ở đây. Kỹ sư thường giỏi đo, nhưng không phải lúc nào cũng biết vì sao một cách tách hay cách viết lại hợp lý về mặt ngôn ngữ. Một cuộc thảo luận có cả hai góc nhìn thường dẫn tới quy ước bền hơn.
Những điều nên tránh
Đóng góp thiện chí vẫn có thể thành gánh nặng nếu không để ý. Một số việc nên tránh khi tham gia dự án của người khác:
- Gửi yêu cầu gộp lớn chưa bàn trước. Viết lại cả một mô-đun mà không hỏi ý người duy trì thường bị từ chối, dù mã có tốt.
- Gửi mã do AI sinh mà không hiểu. Dùng trợ lý lập trình không có gì sai, nhưng bạn phải đọc, chạy kiểm thử và giải thích được từng dòng. Nhiều dự án đã phải đặt quy định riêng vì nhận quá nhiều đóng góp sinh tự động kém chất lượng; đọc quy định đó nếu có.
- Đưa dữ liệu không rõ quyền vào kho. Thêm một tệp từ điển hay kho câu lấy từ nguồn có bản quyền có thể gây rắc rối pháp lý cho cả dự án.
- Mở báo lỗi chỉ để hỏi cách dùng cơ bản. Dùng kênh thảo luận hoặc hỏi đáp nếu dự án có.
- Đòi tính năng theo kiểu ra lệnh. Đề xuất tính năng nên kèm lý do, trường hợp sử dụng và tốt nhất là sẵn sàng tự làm một phần.
- Bỏ dở mà không báo. Nếu đã nhận việc mà không làm tiếp được, để lại một dòng để người khác nhận.
Những điều này áp dụng cho mọi dự án mã nguồn mở, nhưng càng quan trọng với dự án tiếng Việt vì số người duy trì ít, thời gian của họ quý.
Bắt đầu một dự án mới, hay góp vào dự án sẵn có?
Nhiều bạn trẻ hào hứng tự viết một thư viện tách từ hay phục hồi dấu mới. Đó là bài tập học rất tốt, nhưng trước khi công bố như một dự án cho cộng đồng, nên tự hỏi: dự án mới giải quyết điều gì mà các dự án sẵn có chưa làm được, và mình có thời gian duy trì nó trong vài năm không. Cộng đồng tiếng Việt đã có khá nhiều thư viện bị bỏ dở sau vài tháng, để lại người dùng không biết đi đâu.
Nếu điều bạn muốn làm có thể là một tính năng của dự án sẵn có, góp vào đó thường có ích hơn. Nếu thật sự cần dự án mới, hãy chuẩn bị từ đầu những thứ giúp nó sống lâu: giấy phép rõ ràng, hướng dẫn đóng góp, bộ kiểm thử, tài liệu, và một ghi chú trung thực về tình trạng duy trì. Một dòng "dự án học tập, không còn duy trì" giúp người dùng hơn là im lặng.
Nếu buộc phải dừng một dự án, cách tử tế là lưu trữ kho mã ở trạng thái chỉ đọc, ghi rõ lý do và giới thiệu dự án thay thế nếu biết. Người dùng sẽ không phải đoán dự án còn sống hay đã chết.
Câu hỏi thường gặp
Không biết lập trình thì có góp được cho dự án xử lý tiếng Việt không?
Có. Bạn có thể kiểm kết quả của công cụ với văn bản thật và báo lỗi, sửa lỗi chính tả trong tài liệu, viết hướng dẫn bằng tiếng Việt, góp ý quy ước ngôn ngữ, hay giúp gán nhãn dữ liệu cho dự án mở. Người có nền ngôn ngữ học đặc biệt hữu ích với các quyết định về quy ước.
Đóng góp mã nguồn mở có ảnh hưởng tới hợp đồng lao động không?
Có thể có. Một số công ty có quy định về sở hữu trí tuệ với sản phẩm nhân viên làm, kể cả ngoài giờ. Trước khi đóng góp đều đặn, nhất là trong lĩnh vực gần với công việc, nên đọc hợp đồng và quy định nội bộ, hỏi bộ phận phụ trách nếu chưa rõ.
Người duy trì không trả lời yêu cầu gộp mã thì làm gì?
Chờ một thời gian hợp lý, thường vài tuần, rồi nhắc nhẹ một lần. Nếu dự án có vẻ không còn duy trì, xem có bản rẽ nhánh nào đang hoạt động không. Rẽ nhánh riêng là quyền của bạn theo giấy phép, nhưng nên ghi rõ nguồn gốc và lý do.
Có nên dùng trợ lý AI để viết ca kiểm thử không?
Có thể dùng để gợi ý, nhưng ca kiểm thử tiếng Việt do AI viết thường thiếu đúng những trường hợp khó nhất như ký tự tổ hợp hay kiểu dấu cũ, và đôi khi ghi kỳ vọng sai. Bạn cần tự kiểm từng ca, chạy thật, và hiểu vì sao ca đó quan trọng.
Đóng góp cho dự án quốc tế có phần tiếng Việt thì khác gì?
Dự án quốc tế thường có quy trình chặt hơn và người xem xét không đọc được tiếng Việt. Bạn cần giải thích bằng tiếng Anh vì sao thay đổi đúng với tiếng Việt, kèm ví dụ và nguồn nếu có. Đây là cách hiệu quả để tiếng Việt được xử lý tốt hơn trong các công cụ phổ biến toàn cầu.
Giấy phép của dự án ảnh hưởng gì tới đóng góp của mình?
Khi đóng góp, thông thường mã của bạn được phát hành theo giấy phép của dự án. Một số dự án yêu cầu ký thoả thuận đóng góp, có khi chuyển hoặc cấp thêm quyền cho người duy trì. Đọc kỹ trước khi ký để biết mình đồng ý với điều gì.