Bài viết này cũng có sẵn bằng tiếng Hàn, nhờ Dohyung Ahn!
Thom Parkin đã đưa ra một điểm tuyệt vời trong bình luận của một bài viết trước của tôi:
Lời khuyên tuyệt vời. Nhưng bạn bỏ lỡ một điểm [cuối] rất quan trọng. Vì đây là Mã nguồn Mở, một khi bạn đã tìm ra chi tiết của tính năng/chức năng nơi tài liệu hơi nhẹ, BẠN NÊN CẬP NHẬT TÀI LIỆU VÀ GỬI PULL REQUEST. Theo cách đó toàn bộ cộng đồng được hưởng lợi, và bạn thậm chí có thể đạt được một chút "uy tín lập trình viên" cho sự tham gia của bạn!
Tôi vui Thom đã nhắc đến điều này, vì nó rất quan trọng. Sửa tài liệu là cách dễ dàng nhất để bắt đầu đóng góp lại cho các dự án bạn dùng và yêu thích.
Đóng góp đầu tiên của tôi cho các dự án như Rails, Rubinius, và Elixir đều là sửa tài liệu. Tôi đã làm các điều chỉnh nhỏ để làm cho mọi thứ rõ ràng hơn, giải thích một số thứ bạn chỉ có thể khám phá bằng cách đọc mã, thậm chí chỉ sửa định dạng hỏng. Tất cả những điều này đều là cách nhanh, dễ dàng để giúp một số dự án mã nguồn mở lớn. Ngay cả khi chúng là đóng góp duy nhất của tôi cho một dự án, chúng vẫn đã giúp người dùng tương lai, và Tương Lai Tôi. Và đó chính là cái mà mã nguồn mở quan tâm.
Tại sao sửa tài liệu là cách tuyệt vời để bắt đầu
Sửa tài liệu là cách ít đáng sợ nhất để đóng góp cho một dự án lớn như Rails:
Bạn không phải thiết lập dự án để sửa bug. Vì bạn chỉ cập nhật tài liệu, bạn không phải chạy test hay ứng dụng. Đôi khi, bạn thậm chí không phải clone dự án về máy – bạn có thể làm thay đổi ngay trên GitHub!
Nếu maintainer yêu cầu bạn thay đổi pull request, chúng thường là vấn đề từ ngữ hay gu thẩm mỹ. Những loại thay đổi đó dễ chấp nhận hơn là phê phán mã của bạn. Và nó dễ hơn cho bạn để làm những thay đổi đó, vì bạn không phải cập nhật test hay mã, chỉ từ ngữ.
Tài liệu khó cho maintainer dự án, nên cập nhật được trân trọng. Thường, tác giả quá gần với mã để hiểu nơi nào gây nhầm lẫn. Họ cần các nhà phát triển mới hơn để nói cho họ biết tài liệu cần giúp đỡ ở đâu. Cần thực hành để nhìn dự án của bạn như người mới bắt đầu, và không phải ai cũng xây dựng kỹ năng đó.
Cuối cùng, bạn đang bắt đầu xây dựng mối quan hệ với maintainer, với một thay đổi tác động thấp. Bạn không thay đổi hướng dự án, như bạn sẽ làm nếu đóng góp một tính năng toàn bộ. Vì vậy thay đổi của bạn dễ dàng hơn cho maintainer review, và họ thường phản hồi bạn nhanh hơn. Pull request của bạn sẽ không bị kẹt ở giai đoạn "Đây có phải ý tưởng hay không?".
Khi bạn tiếp tục xây dựng mối quan hệ đó, bạn sẽ bắt đầu được nhìn nhận là một người đóng góp đáng tin cậy. Pull request của bạn sẽ được review nhanh hơn, và sẽ dễ dàng hơn cho cả hai để nói chuyện qua các yêu cầu tính năng phức tạp và sửa lỗi hơn.
Chúng dễ bắt đầu hơn, dễ làm hơn, và xu hướng được merge nhanh hơn. Vậy tại sao đóng góp đầu tiên của bạn không phải là sửa tài liệu?
Bắt đầu đóng góp tài liệu đã cập nhật
Có một cách quan trọng đóng góp cập nhật tài liệu giống như sửa bug: Cả hai đều dựa vào việc nhạy cảm với những thứ cảm thấy sai. Bạn phải chú ý.
Khi bạn gặp hành vi bạn không mong đợi, có thể là lúc cập nhật tài liệu. Nếu bạn phải lặn lội vào mã để giải quyết vấn đề, bạn có thể cũng muốn nói cho người khác biết. Bạn thậm chí nên nhạy cảm với định dạng hỏng và lỗi chính tả trong tài liệu bạn đọc. Nếu bạn không sửa nó, ai sẽ sửa?
Một khi bạn có ý tưởng tốt về nơi làm thay đổi và bạn muốn từ ngữ như thế nào, làm thay đổi của bạn và gửi pull request qua GitHub.
Nếu bạn vẫn đang cố gắng quyết định cách tốt nhất để cập nhật tài liệu, hãy mở issue trên GitHub. Nó có thể giống như thế này:
"Hey, điều này gây nhầm lẫn cho tôi. Tôi đang nghĩ cập nhật nó trông giống như thế này: … Bạn nghĩ sao? Có điều gì khác tôi nên nhắc không?" Cùng nhau, bạn có thể tìm ra từ ngữ thỏa mãn mọi người.
Cuối cùng, đừng nản lòng nếu bạn không nhận được phản hồi. Dự án lớn có nhiều việc xảy ra, nên dễ dàng cho đóng góp của bạn rơi qua kẽ. Sau một tuần hoặc thế, nếu bạn vẫn không nghe tin từ ai, hãy hỏi maintainer lại.
Tài liệu thường là điều đầu tiên bạn gặp khi làm việc với một thư viện, vì vậy quan trọng rằng nó chi tiết và rõ ràng.
Vì vậy khi bạn bối rối về mã bạn dùng, hoặc phải lặn lội vào source, hãy làm cho người tiếp theo dễ dàng hơn. Viết một cập nhật nhanh, và đóng góp nó lại. Đó là cách dễ dàng nhất tôi biết để trở thành một người đóng góp mã nguồn mở.
Bài viết này ban đầu được gửi cho những người trong danh sách của tôi. Để đọc thêm giống như vậy, đăng ký ở đây!