Bài báo này cũng có sẵn bằng tiếng Hàn, cảm ơn Dohyung Ahn!
Thom Parkin đã đưa ra một quan điểm tuyệt vời trong nhận xét của một bài báo trước đây của tôi:
Lời khuyên tuyệt vời. Nhưng bạn đã bỏ lỡ một điểm rất quan trọng [cuối cùng]. Vì đây là Mã nguồn mở, một khi bạn đã tìm hiểu chi tiết về tính năng / chức năng đó trong đó tài liệu hơi nhẹ, BẠN NÊN CẬP NHẬT DOCS VÀ GỬI YÊU CẦU ĐẦY ĐỦ. Bằng 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 số "tín dụng lập trình viên" cho sự tham gia của mình!
Tôi rất vui vì Thom đã đề cập đến vấn đề này, vì nó rất quan trọng . Sửa chữa tài liệu là cách dễ nhất để bắt đầu đóng góp trở lại cho các dự án bạn sử dụng và yêu thích.
Những đóng góp đầu tiên của tôi cho các dự án như Rails, Rubinius và Elixir đều là các bản sửa lỗi tài liệu. Tôi đã thực hiện các chỉnh sửa nhỏ để làm cho mọi thứ rõ ràng hơn, giải thích một số điều mà bạn chỉ có thể khám phá bằng cách đọc mã, thậm chí chỉ sửa định dạng bị hỏng. Đây đều là những cách nhanh chóng, dễ dàng để giúp thực hiện một số dự án mã nguồn mở lớn. Ngay cả khi họ là những đóng góp duy nhất của tôi cho một dự án, họ vẫn giúp đỡ những người dùng trong tương lai và Tôi trong tương lai. Và đó là tất cả những gì về nguồn mở.
Tại sao sửa lỗi tài liệu lại là một cách tuyệt vời để bắt đầu
Các bản sửa lỗi tài liệu là cách ít đáng sợ nhất để đóng góp vào một dự án lớn như Rails:
-
Bạn không phải thiết lập dự án để sửa lỗi . Vì bạn chỉ đang cập nhật tài liệu nên bạn không cần phải kiểm tra hoặc chạy ứng dụng. Đôi khi, bạn thậm chí sẽ không phải sao chép dự án vào máy của mình - bạn có thể thực hiện thay đổi của mình ngay trên GitHub!
-
Nếu người bảo trì yêu cầu bạn thực hiện các thay đổi đối với yêu cầu kéo của bạn, chúng thường là vấn đề về từ ngữ hoặc khẩu vị . Những loại thay đổi đó có thể dễ gây khó chịu hơn là những lời chỉ trích về mã của bạn. Và bạn sẽ dễ dàng thực hiện những thay đổi đó hơn vì bạn không phải cập nhật các bài kiểm tra hoặc mã, chỉ cần từ.
-
Tài liệu là khó cho người bảo trì dự án, vì vậy các bản cập nhật được đánh giá cao . Thông thường, các tác giả quá gần với mã để hiểu các phần khó hiểu nằm ở đâu. Họ cần các nhà phát triển khác, mới hơn cho họ biết nơi tài liệu cần trợ giúp. Cần phải thực hành để xem dự án của bạn như một người mới bắt đầu và không phải ai cũng xây dựng được kỹ năng đó.
-
Cuối cùng, bạn đang bắt đầu xây dựng mối quan hệ với người bảo trì, với một thay đổi có tác động thấp . Bạn sẽ không thay đổi hướng của dự án, giống như bạn sẽ làm nếu bạn đang đóng góp toàn bộ tính năng. Vì vậy, thay đổi của bạn dễ dàng hơn để người bảo trì xem xét và họ thường sẽ phản hồi bạn nhanh hơn. Yêu cầu hợp nhất của bạn sẽ không gặp khó khăn trong phần "Đây có phải là một ý tưởng hay không?" giai đoạn.
Khi bạn tiếp tục xây dựng mối quan hệ đó, bạn sẽ bắt đầu được coi là một người đóng góp đáng tin cậy. Yêu cầu kéo của bạn sẽ được xem xét nhanh hơn và cả hai bạn sẽ dễ dàng trao đổi thông qua các yêu cầu tính năng phức tạp hơn và sửa lỗi.
Chúng dễ bắt đầu hơn, dễ thực hiện hơn và chúng có xu hướng hòa nhập nhanh hơn. Vậy tại sao đóng góp đầu tiên của bạn không phải là bản sửa lỗi tài liệu?
Cách bắt đầu đóng góp lại tài liệu cập nhật
Có một cách quan trọng để đóng góp các bản cập nhật tài liệu cũng giống như sửa lỗi: Cả hai đều dựa vào việc nhạy cảm với những điều cảm thấy không ổn . Bạn phải chú ý.
Khi bạn gặp phải hành vi mà bạn không mong đợi, có thể đã đến lúc cập nhật tài liệu. Nếu bạn phải đi sâu vào mã để giải quyết một vấn đề, bạn cũng có thể muốn nói với người khác về nó. Bạn thậm chí nên nhạy cảm với định dạng bị 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ẽ?
Khi bạn đã biết rõ về nơi thực hiện thay đổi và cách bạn muốn diễn đạt nó, hãy thực hiện thay đổi và gửi yêu cầu kéo 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ở một vấn đề trên GitHub. Nó có thể là một cái gì đó như thế này:
“Này, điều này khiến tôi bối rối. Tôi đã nghĩ đến việc cập nhật nó để trông giống như thế này:… Bạn nghĩ sao? Tôi nên đề cập đến điều gì khác không? ” Cùng nhau, bạn có thể đưa ra những từ ngữ làm hài lòng tất cả 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. Các dự án lớn đang diễn ra rất nhiều, vì vậy đóng góp của bạn rất dễ bị phá vỡ. Trong một tuần hoặc lâu hơn, nếu bạn vẫn không nhận được phản hồi từ bất kỳ ai, hãy hỏi lại người bảo trì .
Tài liệu thường là thứ đầu tiên bạn gặp phải khi làm việc với thư viện, vì vậy, điều quan trọng là nó phải chi tiết và rõ ràng.
Vì vậy, khi bạn bối rối về mã bạn sử dụng hoặc phải đi sâu vào nguồn, hãy giúp người tiếp theo hiểu dễ dàng hơn. Viết cập nhật nhanh và đóng góp lại. Đó là cách dễ nhất mà tôi biết để trở thành cộng tác viên nguồn mở.
Bài viết này ban đầu được gửi đến những người trong danh sách của tôi. Để đọc nhiều hơn như nó, hãy đăng ký tại đây!