Tránh tình trạng mở rộng phạm vi¶
"Sự mở rộng phạm vi" xảy ra khi danh sách các vấn đề được giải quyết hoặc các tính năng được triển khai trong một đóng góp cụ thể tăng lên đáng kể so với dự định ban đầu khi bắt đầu công việc. Bạn bắt đầu với một vấn đề đơn giản; sau đó phát hiện ra một vấn đề có liên quan chặt chẽ và quyết định đưa cả bản sửa lỗi đó vào; rồi đến vấn đề thứ ba… và trước khi bạn kịp nhận ra, bạn đã có một yêu cầu kéo (pull request) giải quyết 5 vấn đề và bổ sung 3 tính năng mới, bao gồm hàng chục tệp tin.
Việc phạm vi dự án bị mở rộng là điều ai cũng từng gặp phải. Đây là một khái niệm quá đỗi quen thuộc với các nhà phát triển dày dạn kinh nghiệm; ai trong chúng ta cũng đã từng trải qua điều này nhiều lần và phải đối mặt với tất cả những vấn đề đi kèm.
Có những lý do rất thực tế để tránh tình trạng mở rộng phạm vi. Càng đóng góp lớn, việc xử lý càng trở nên khó khăn. Việc xác định các trường hợp ngoại lệ hoặc các vấn đề tiềm ẩn cũng trở nên phức tạp hơn, điều này có nghĩa là chất lượng tổng thể của đóng góp có thể bị giảm sút. Việc đánh giá cũng trở nên khó khăn hơn khi người đánh giá phải xử lý nhiều bối cảnh, có thể không liên quan đến nhau. Một đóng góp lớn hơn đồng nghĩa với nhiều bình luận đánh giá hơn, và với tư cách là người đóng góp, bạn có thể gặp khó khăn khi theo dõi nhiều chuỗi bình luận đánh giá. Ngay cả trải nghiệm GitHub của bạn cũng sẽ bị ảnh hưởng - giao diện người dùng của GitHub sẽ chậm lại khi kích thước của PR tăng lên, đồng nghĩa với việc điều hướng các tệp qua giao diện GitHub và cố gắng để lại bình luận đánh giá sẽ ngày càng khó khăn hơn.
Bất cứ khi nào bạn thấy có lý do để bổ sung bất kỳ nội dung nào vào bản đóng góp của mình mà nội dung đó không được nêu rõ trong đề xuất ban đầu hoặc báo cáo lỗi, bạn nên cân nhắc xem liệu mình có đang đi vào tình trạng mở rộng phạm vi (scope creep) hay không. Có hai tính năng riêng biệt có thể được triển khai độc lập không? Có thể triển khai một tính năng với một hạn chế hoặc lỗi đã biết, và sửa lỗi đó trong một pull request tiếp theo không? Có phần nào của việc sửa lỗi độc lập với phần khác không? Nếu một phần của thay đổi có thể được loại bỏ mà không làm thay đổi đóng góp ban đầu, thì có lẽ nên loại bỏ nó.
Phát triển phần mềm luôn là một quá trình cải tiến từng bước. Mỗi đóng góp riêng lẻ nên giúp cơ sở mã trở nên tốt hơn sau khi được hợp nhất, nhưng việc để lại các lỗi hoặc một phần của tính năng để cải thiện trong tương lai là hoàn toàn chấp nhận được. Điều đó có thể có nghĩa là chia một yêu cầu kéo (pull request) thành nhiều phần có thể được xem xét độc lập, hoặc tạo một vấn đề (issue) để người khác có thể điều tra và giải quyết vấn đề.
Việc giới hạn phạm vi của mỗi bài viết sẽ có lợi cho tất cả những người liên quan, bao gồm cả bạn. Các nhà phản biện của bạn, và cả chính bạn, sẽ đánh giá cao điều này.