Đánh giá yêu cầu kéo¶
Chúng tôi luôn hoan nghênh các bài đánh giá từ các cộng tác viên, bất kể họ có kinh nghiệm ở mức độ nào.
Tại sao phải xem xét các đóng góp?¶
Mọi đóng góp được gửi đến đều cần được xem xét, bất kể đó là đóng góp từ thành viên nhóm nòng cốt hay người đóng góp lần đầu. Ai cũng có thể bỏ sót điều gì đó. Quy trình xem xét được thiết lập nhằm tạo thêm một lớp bảo đảm.
Mục đích của quy trình rà soát là đảm bảo tất cả nội dung, bao gồm mã nguồn và tài liệu, được loại bỏ lỗi và dễ bảo trì nhất có thể. Bất kỳ đóng góp nào giúp đạt được mục tiêu này đều được hoan nghênh. Điều này có thể bao gồm những việc đơn giản như sửa lỗi chính tả, đến việc phát hiện các trường hợp ngoại lệ trong việc sử dụng API mà hệ thống kiểm tra hiện tại chưa phát hiện được. Bạn cũng có thể đề xuất các phương án để làm cho quy trình kiểm thử trở nên vững chắc hơn, hoặc đưa ra ý kiến về cách tổ chức kiến trúc tổng thể của các thay đổi sao cho chúng dễ bảo trì hoặc mở rộng hơn.
Tôi có thể xem lại được không?¶
Đúng vậy! Bạn có thể gửi phản hồi cho bất kỳ yêu cầu kéo nào đang mở trên BeeWare Docs Tools.
Là một người đóng góp lần đầu, bạn hãy thoải mái xem xét bất kỳ yêu cầu pull nào mà bạn thấy, ngay cả khi nó được gửi bởi một thành viên trong nhóm nòng cốt. Nếu bạn là người mới, có thể bạn sẽ chưa nắm rõ bối cảnh tổng thể của dự án; nhưng chúng tôi luôn nỗ lực giữ cho cơ sở mã dễ tiếp cận bất kể trình độ kinh nghiệm của bạn. Nếu có điều gì trong mã nguồn khiến bạn cảm thấy khó hiểu, điều đó có thể cho thấy cần có thêm tài liệu hướng dẫn (cả trong mã nguồn hoặc dưới dạng tài liệu thiết kế độc lập).
Đóng góp vào việc đánh giá yêu cầu kéo¶
Đánh giá yêu cầu kéo
Đánh giá yêu cầu kéo¶
Mọi người đều được chào đón tham gia đánh giá bất kỳ đóng góp nào cho dự án BeeWare. Trước khi bắt đầu, có một số điều quan trọng cần lưu ý.
Hãy suy nghĩ kỹ trước khi đánh giá¶
Trước khi bắt tay vào viết đánh giá, HÃY SUY NGHĨ KỸ. Với tư cách là người đánh giá, chúng ta nên cân nhắc xem phản hồi mà mình sắp gửi đi có phải là:
- Đúng vậy. Hãy luôn cố gắng đưa ra những gợi ý và thông tin chính xác.
- Hữu ích. Chúng tôi đang cung cấp hướng dẫn về cách cải thiện bản đề xuất; hướng dẫn này cần chỉ ra rõ ràng nguyên nhân của vấn đề hoặc trường hợp sử dụng chưa được xem xét, và tốt nhất là đề xuất một phương án để giải quyết hoặc đáp ứng mối quan ngại đó.
- Thật truyền cảm hứng. Chính chúng ta phải truyền cảm hứng để tác giả muốn thực hiện những thay đổi mà chúng ta đề xuất.
- Điều này là cần thiết. Chúng tôi mong rằng tác giả sẽ đọc tất cả những gì chúng tôi đăng tải; chúng ta phải tôn trọng thời gian và công sức của họ bằng cách chỉ đăng tải khi thực sự cần thiết.
- Tử tế. Có nhiều cách để truyền đạt cùng một ý kiến phản hồi; chúng ta cần đảm bảo rằng mình luôn lựa chọn cách diễn đạt tử tế, động viên và mang tính xây dựng.
Hoàn toàn có thể vừa SUY NGHĨ vừa đưa ra nhận xét hiệu quả. Những khái niệm được đề cập ở trên không có nghĩa là bạn không được chỉ ra những vấn đề mà bạn phát hiện trong một PR. Các cộng tác viên sẽ không có cơ hội cải thiện đóng góp của mình nếu họ không biết những điểm cần cải thiện. Điều quan trọng là bạn phải luôn lưu ý đến cách bạn trình bày phản hồi này. Hãy cố gắng loại bỏ yếu tố cá nhân khỏi đánh giá của bạn. Thay vì nói "Bạn đã mắc lỗi", bạn có thể nói "Mã này có thể được cải thiện". Hãy đánh giá mã, chứ không phải tác giả.
Điều quan trọng là đừng quên đưa ra những phản hồi tích cực bên cạnh việc chỉ ra những điểm cần cải thiện. Ví dụ, nếu những thay đổi đó đặc biệt hữu ích, có một ý tưởng sáng tạo nào đó, hoặc bạn được giới thiệu về một API mà trước đây bạn chưa biết, hãy cho tác giả biết! Đừng bao giờ đánh giá thấp tác động của việc khen ngợi những điều ai đó đã làm đúng hoặc làm tốt, ngay cả khi tất cả những vấn đề khác mà bạn đã chỉ ra đều là những vấn đề cần được giải quyết.
Đề xuất đánh giá trên GitHub¶
Giao diện đánh giá trên GitHub có một cơ chế đề xuất thay đổi, cho phép bạn cung cấp chính xác nội dung thay thế mà bạn đề xuất để thay thế cho nội dung hiện tại. Hãy lưu ý rằng, cho đến khi được chấp nhận và cam kết, những thay đổi được đề xuất này sẽ không được xử lý qua các bước kiểm tra trước khi cam kết (pre-commit) và kiểm tra linting. Do đó, tính năng này nên được sử dụng cho những thay đổi nhỏ, vì thay đổi được đề xuất càng lớn thì khả năng gây ra sự cố càng cao.