Mọi người đều có thể đóng góp cho OpenXLA và chúng tôi trân trọng đóng góp của mọi người. Bạn có thể đóng góp theo một số cách, bao gồm:
Trả lời câu hỏi trên các diễn đàn thảo luận của OpenXLA (openxla-discuss)
Cải thiện hoặc mở rộng tài liệu của OpenXLA
Đóng góp vào cơ sở mã của OpenXLA
Đóng góp theo bất kỳ cách nào ở trên cho hệ sinh thái thư viện rộng lớn hơn được tạo trên OpenXLA
Dự án OpenXLA tuân thủ Nguyên tắc cộng đồng nguồn mở của Google.
Trước khi bắt đầu
Ký Thỏa thuận cấp phép cộng tác viên
Nội dung đóng góp cho dự án này phải đi kèm với Thoả thuận cấp phép cộng tác viên (CLA). Bạn (hoặc chủ lao động của bạn) giữ bản quyền đối với nội dung bạn đóng góp. Điều này chỉ đơn giản là cấp cho chúng tôi quyền sử dụng và phân phối lại các khoản đóng góp của bạn trong khuôn khổ dự án.
Nếu bạn hoặc công ty hiện tại của bạn đã ký Thoả thuận cấp phép nội dung của Google (ngay cả khi đó là cho một dự án khác), thì có thể bạn không cần làm lại.
Truy cập <https://cla.developers.google.com/> để xem các thoả thuận hiện tại của bạn hoặc để ký một thoả thuận mới.
Xem lại Quy tắc ứng xử
Dự án này tuân theo Quy tắc ứng xử của Tenor.
Quy trình đóng góp
Hướng dẫn cho nhà phát triển
Để xem hướng dẫn về cách thiết lập môi trường phát triển cho OpenXLA, bao gồm cả việc nhận mã, tạo bản dựng, chạy kiểm thử và gửi các thay đổi, vui lòng tham khảo Hướng dẫn cho nhà phát triển.
Tiêu chuẩn mã
Kiểu lập trình: Chúng tôi tuân theo hướng dẫn kiểu mã của Google. Cụ thể, hãy xem hướng dẫn C/C++ và Python. Tất cả mã được gửi phải tuân thủ nghiêm ngặt các hướng dẫn về quy tắc này.
Những thay đổi nhỏ: Chúng tôi tuân theo các phương pháp kỹ thuật của Google. Cụ thể, hãy quan sát hướng dẫn về cách viết các thay đổi thu gọn. Làm như vậy sẽ làm tăng đáng kể tốc độ hợp nhất mã do cải thiện khả năng xem xét, đồng thời giảm khả năng xảy ra tác dụng phụ ngoài ý muốn của việc thay đổi. Ngay cả khi bạn có một thay đổi lớn, vẫn có nhiều chiến lược để chia nhỏ thành các thay đổi tăng dần.
Phạm vi kiểm thử: Tất cả thay đổi phải bao gồm các chương trình kiểm thử đơn vị thích hợp. Hoạt động kiểm thử đơn vị không được phụ thuộc vào thời gian phần cứng cụ thể (CPU, GPU, v.v.), đồng thời nên sử dụng thoải mái các chế độ mô phỏng và giả để tạo ra hoạt động kiểm thử có tính xác định và tập trung. Những thay đổi đang tìm cách mở rộng mã hiện có mà hiện rất khó kiểm thử phải thực hiện những cải tiến thích hợp cho khả năng kiểm thử.
Tất cả các thay đổi phải bao gồm kết quả đo điểm chuẩn phù hợp trong tiêu đề thay đổi để đảm bảo hiểu rõ lợi ích.
Khi không chắc về các quy ước trong mã, bạn nên kiểm tra mã có sẵn và cố gắng tuân theo các mẫu đã có trong OpenXLA.
Quy trình xem xét
Tất cả nội dung gửi, bao gồm cả bài do thành viên dự án gửi, đều cần được xem xét. Chúng tôi sử dụng yêu cầu lấy dữ liệu GitHub cho mục đích này. Hãy tham khảo trang Trợ giúp GitHub để biết thêm thông tin về cách sử dụng yêu cầu lấy dữ liệu.
Mã phải tuân thủ tất cả các tiêu chuẩn nêu trên trước khi được xem xét. Đây là những trường hợp không bắt buộc và điều quan trọng là người gửi phải đảm bảo mã của họ tuân thủ trước khi yêu cầu xem xét để đảm bảo chấp nhận kịp thời các thay đổi.
Tất cả các kiểm thử đều phải vượt qua. Nếu bạn nhận thấy kiểm thử bị lỗi và vấn đề không liên quan đến môi trường tạo bản dựng hoặc các thay đổi của bạn, vui lòng liên hệ với nhà bảo trì.
Cố gắng tránh phạm vi thiếu trong quá trình xem xét. Đây là trách nhiệm của cả người gửi và người đánh giá. Nếu một thay đổi bắt đầu trở nên quá lớn, hãy cân nhắc chia nhỏ thành nhiều thay đổi.
Trước khi hợp nhất một thay đổi, thay đổi đó sẽ trải qua quy trình kiểm thử nội bộ sử dụng đoạn mã nội bộ cho Google và các nhà cung cấp phần cứng khác. Việc này có thể thêm các bước bổ sung vào quy trình xem xét nếu có lỗi kiểm thử nội bộ mà CI công khai của chúng tôi không phát hiện được. Nhân viên của Google xem xét thay đổi của bạn sẽ thông báo về mọi lần thất bại trong kiểm thử nội bộ và mô tả những điểm cần khắc phục.
Câu hỏi thường gặp
"Sự thay đổi về cơ sở hạ tầng này không liên quan đến quảng cáo của tôi. Vì sao tôi nên làm việc này?"
Nhóm XLA không có nhóm chuyên trách về cơ sở hạ tầng. Do đó, tất cả chúng ta đều phải xây dựng thư viện trợ giúp và tránh các công việc kỹ thuật. Chúng tôi coi đây là hoạt động thường xuyên trong việc thực hiện các thay đổi đối với XLA và mọi người đều mong muốn tham gia. Chúng tôi thường xây dựng cơ sở hạ tầng khi cần thiết trong quá trình viết mã.
Nhân viên đánh giá của XLA có thể yêu cầu bạn xây dựng một số cơ sở hạ tầng (hoặc thực hiện một thay đổi lớn đối với bài PR) cùng với bài PR mà bạn đã viết. Yêu cầu này có vẻ không cần thiết hoặc liên quan đến thay đổi mà bạn đang cố gắng thực hiện. Nguyên nhân có thể là do bạn nhận thấy không nhất quán giữa kỳ vọng của mình về lượng hạ tầng mà bạn cần xây dựng và kỳ vọng của người đánh giá về điều tương tự.
Chúng tôi chấp nhận thông tin không phù hợp trong kỳ vọng! Điều này xảy ra khi bạn mới tham gia một dự án (và đôi khi điều này xảy ra với chúng tôi về các mũ cũ). Có thể các dự án bạn đã thực hiện trước đây có những kỳ vọng khác nhau. Điều này cũng không sao và theo dự kiến! Điều này không có nghĩa là một trong hai dự án này có cách tiếp cận không phù hợp, mà chỉ là khác nhau. Chúng tôi mời bạn thực hiện yêu cầu infra cùng tất cả các nhận xét đánh giá khác như một cơ hội để tìm hiểu những gì chúng tôi mong đợi trong dự án này.
"Tôi có thể giải quyết bình luận của bạn trong tương lai không?"
Một câu hỏi thường gặp về các yêu cầu về cơ sở hạ tầng (hoặc các yêu cầu lớn khác) trong PR là liệu có phải thực hiện thay đổi trong PR ban đầu hay không, hay có thể thực hiện thay đổi đó dưới dạng tiếp nối trong PR sau này hay không.
Nhìn chung, XLA không cho phép tác giả PR giải quyết nhận xét đánh giá bằng PR tiếp theo. Khi người đánh giá quyết định rằng cần giải quyết vấn đề nào đó trong một PR nhất định, chúng tôi thường mong muốn tác giả giải quyết vấn đề đó trong PR đó, ngay cả khi những gì được yêu cầu là một thay đổi lớn. Tiêu chuẩn này áp dụng bên ngoài và cả trong nội bộ Google.
Có một vài lý do khiến XLA chọn cách tiếp cận này.
Sự tin cậy: Thành phần quan trọng nhất là phải nhận được sự tin tưởng của người đánh giá. Trong một dự án nguồn mở, người đóng góp có thể xuất hiện hoặc biến mất theo ý muốn. Sau khi chúng tôi phê duyệt một PR, người đánh giá không có cách nào để đảm bảo rằng mọi hoạt động tiếp theo đã hứa hẹn sẽ thực sự được thực hiện.
Tác động đến các nhà phát triển khác: Nếu bạn đã gửi một bài PR có liên quan đến một phần cụ thể của XLA, thì rất có thể những người khác cũng sẽ xem phần đó. Nếu chúng tôi chấp nhận khoản nợ kỹ thuật trong PR của bạn thì những người đang xem tệp này sẽ bị ảnh hưởng bởi khoản nợ này cho đến khi yêu cầu tiếp theo được gửi.
Băng thông của người đánh giá: Việc trì hoãn thay đổi theo dõi sẽ dẫn đến nhiều chi phí cho những người đánh giá đã quá tải của chúng tôi. Người đánh giá có thể quên nội dung PR đầu tiên là gì trong khi chờ email tiếp theo, điều này khiến lần đánh giá tiếp theo càng khó khăn hơn. Ngoài ra, người đánh giá sẽ phải theo dõi các câu hỏi tiếp theo dự kiến, đảm bảo rằng chúng thực sự xảy ra. Nếu có thể thay đổi để thực sự trực giao với PR ban đầu để một số người đánh giá khác có thể xem xét, thì băng thông sẽ ít gây ra vấn đề hơn. Theo kinh nghiệm của chúng tôi, điều này hiếm khi xảy ra.