Hugging Face's logo

Diffusers documentation

Cách đóng góp cho Diffusers 🧨

You are viewing main version, which requires installation from source. If you'd like regular pip install, checkout the latest stable version (v0.42.1).
Hugging Face's logo
Join the Hugging Face community

and get access to the augmented documentation experience

to get started

Cách đóng góp cho Diffusers 🧨

Nếu bạn sử dụng tác nhân AI để đóng góp, hãy đảm bảo đọc phần Đóng góp có hỗ trợ AI và tác nhân để nắm rõ kỳ vọng và hướng dẫn của chúng tôi.

Chúng tôi ❤️ những đóng góp từ cộng đồng mã nguồn mở! Mọi người đều được chào đón, và mọi hình thức tham gia – không chỉ là viết mã – đều được đánh giá cao và trân trọng. Trả lời câu hỏi, hỗ trợ người khác, chủ động kết nối và cải thiện tài liệu đều có giá trị vô cùng lớn đối với cộng đồng, vì vậy đừng ngại ngần mà hãy tham gia nếu bạn sẵn sàng!

Mọi người đều được khuyến khích bắt đầu bằng cách chào 👋 trong kênh Discord công khai của chúng tôi. Chúng tôi thảo luận về các xu hướng mới nhất trong mô hình khuếch tán, đặt câu hỏi, khoe các dự án cá nhân, hỗ trợ lẫn nhau trong việc đóng góp, hoặc đơn giản là trò chuyện ☕. Join us on Discord

Dù bạn chọn cách đóng góp nào, chúng tôi luôn nỗ lực trở thành một phần của cộng đồng cởi mở, thân thiện và tử tế. Vui lòng đọc mã ứng xử của chúng tôi và lưu ý tôn trọng nó trong các tương tác của bạn. Chúng tôi cũng khuyến khích bạn làm quen với các hướng dẫn đạo đức định hướng cho dự án của chúng tôi và yêu cầu bạn tuân thủ cùng các nguyên tắc về tính minh bạch và trách nhiệm.

Chúng tôi rất coi trọng phản hồi từ cộng đồng, vì vậy xin đừng ngại lên tiếng nếu bạn cho rằng mình có phản hồi giá trị có thể giúp cải thiện thư viện - mọi tin nhắn, bình luận, issue và pull request (PR) đều được đọc và xem xét.

Tổng quan

Bạn có thể đóng góp theo nhiều cách, từ việc trả lời các câu hỏi trong issues và discussions cho đến việc thêm các mô hình diffusion mới vào thư viện lõi.

Dưới đây là tổng quan về các cách đóng góp khác nhau, được sắp xếp theo mức độ cam kết thời gian tăng dần. Tất cả đều có giá trị đối với cộng đồng.

Như đã đề cập ở trên, mọi đóng góp đều có giá trị đối với cộng đồng. Dưới đây, chúng ta sẽ giải thích chi tiết hơn về từng loại đóng góp.

Đối với các đóng góp từ 4 đến 10, ngoại trừ số 6 nằm trên Hub, bạn sẽ cần mở một PR. Cách thực hiện được giải thích chi tiết trong Mở một pull request.

1. Đặt câu hỏi và trả lời câu hỏi trên GitHub Discussions hoặc trên Discord

Mọi câu hỏi hoặc bình luận liên quan đến thư viện Diffusers có thể được đặt trên GitHub Discussions hoặc trên Discord. Các câu hỏi và bình luận như vậy bao gồm (nhưng không giới hạn ở):

  • Báo cáo về các thí nghiệm huấn luyện hoặc suy luận nhằm chia sẻ kiến thức
  • Trình bày các dự án cá nhân
  • Câu hỏi về các ví dụ huấn luyện không chính thức
  • Đề xuất dự án
  • Phản hồi chung
  • Tóm tắt bài báo
  • Yêu cầu hỗ trợ cho các dự án cá nhân được xây dựng dựa trên thư viện Diffusers
  • Câu hỏi chung
  • Các vấn đề đạo đức liên quan đến mô hình khuếch tán
  • …

Mọi câu hỏi được đặt ra trên GitHub Discussions hoặc Discord đều khuyến khích cộng đồng chia sẻ kiến thức một cách công khai và rất có thể sẽ giúp ích cho một người mới trong tương lai có cùng câu hỏi mà bạn đang gặp phải. Vui lòng đặt bất kỳ câu hỏi nào mà bạn có thể có. Với tinh thần tương tự, bạn đang hỗ trợ rất lớn cho cộng đồng bằng cách trả lời những câu hỏi như vậy, vì qua đó bạn đang công khai ghi lại kiến thức để mọi người cùng học hỏi.

Vui lòng lưu ý rằng bạn càng bỏ nhiều công sức vào việc đặt câu hỏi hoặc trả lời, chất lượng của kiến thức được tài liệu hóa công khai càng cao. Tương tự, các câu hỏi được đặt đúng cách và các câu trả lời chất lượng cao sẽ tạo nên một cơ sở dữ liệu kiến thức chất lượng cao, có thể truy cập bởi tất cả mọi người, trong khi các câu hỏi hoặc câu trả lời kém chất lượng sẽ làm giảm chất lượng tổng thể của cơ sở dữ liệu kiến thức công khai. Tóm lại, một câu hỏi hoặc câu trả lời chất lượng cao phải chính xác, ngắn gọn, liên quan, dễ hiểu, dễ tiếp cận và được định dạng/đặt câu tốt. Để biết thêm thông tin, hãy xem phần Cách viết một issue tốt.

LƯU Ý về các kênh: GitHub Discussions được các công cụ tìm kiếm lập chỉ mục và mỗi chủ đề đều có thể được liên kết, nên các câu hỏi và câu trả lời được đăng ở đó vẫn có thể được tìm thấy cho người tiếp theo gặp cùng vấn đề. Ngược lại, Discord có định dạng kiểu trò chuyện, khuyến khích giao tiếp qua lại nhanh chóng. Mặc dù khả năng cao là bạn sẽ nhận được câu trả lời cho câu hỏi của mình nhanh hơn trên Discord, nhưng câu hỏi của bạn sẽ không còn hiển thị theo thời gian và việc tìm kiếm thông tin được đăng từ lâu sẽ khó khăn hơn nhiều. Do đó, chúng tôi khuyến khích sử dụng GitHub Discussions cho các câu hỏi và câu trả lời mang tính lâu dài. Nếu một cuộc trò chuyện trên Discord dẫn đến một kết luận thú vị, hãy đăng kết quả đó dưới dạng một thảo luận để người đọc trong tương lai có thể tìm thấy.

2. Mở các vấn đề mới trên tab GitHub issues

Thư viện 🧨 Diffusers vững chắc và đáng tin cậy nhờ vào những người dùng đã thông báo cho chúng tôi về các vấn đề mà họ gặp phải. Vì vậy, xin cảm ơn bạn đã báo cáo sự cố.

Hãy nhớ rằng, các issue trên GitHub được dành riêng cho các câu hỏi kỹ thuật liên quan trực tiếp đến thư viện Diffusers, báo cáo lỗi, yêu cầu tính năng hoặc phản hồi về thiết kế thư viện.

Nói ngắn gọn, điều này có nghĩa là mọi thứ không liên quan đến mã nguồn của thư viện Diffusers (bao gồm cả tài liệu) không nên được đặt dưới dạng issue, mà nên hỏi trên GitHub Discussions hoặc Discord.

Vui lòng xem xét các hướng dẫn sau khi mở một vấn đề mới:

  • Hãy đảm bảo bạn đã tìm kiếm xem vấn đề của bạn đã được hỏi trước đó chưa (sử dụng thanh tìm kiếm trên GitHub dưới mục Issues).
  • Vui lòng không bao giờ báo cáo một vấn đề mới trên một vấn đề khác (liên quan). Nếu có một vấn đề khác liên quan chặt chẽ, hãy mở một vấn đề mới và liên kết đến vấn đề liên quan đó.
  • Hãy đảm bảo vấn đề của bạn được viết bằng tiếng Anh.
  • Kiểm tra xem vấn đề của bạn có thể được giải quyết bằng cách cập nhật lên phiên bản Diffusers mới nhất hay không. Trước khi đăng vấn đề, vui lòng đảm bảo rằng python -c "import diffusers; print(diffusers.__version__)" cao hơn hoặc khớp với phiên bản Diffusers mới nhất.
  • Hãy nhớ rằng bạn càng bỏ nhiều công sức để mở một issue mới, chất lượng câu trả lời của bạn sẽ càng cao và chất lượng tổng thể của các issue trong Diffusers cũng sẽ tốt hơn.

Các vấn đề mới thường bao gồm những nội dung sau.

2.1. Báo cáo lỗi tối giản, có thể tái hiện

Báo cáo lỗi luôn phải có một đoạn mã tái hiện được và cần tối giản, ngắn gọn nhất có thể. Cụ thể hơn, điều này có nghĩa là:

  • Hạn chế phạm vi lỗi càng nhiều càng tốt, đừng chỉ ném cả file mã nguồn của bạn vào đó.
  • Định dạng mã của bạn.
  • Không bao gồm bất kỳ thư viện bên ngoài nào ngoại trừ Diffusers nếu chúng phụ thuộc vào các thư viện đó.
  • Luôn cung cấp đầy đủ thông tin về môi trường của bạn; để làm điều này, bạn có thể chạy: diffusers-cli env trong shell và sao chép-dán thông tin hiển thị vào issue.
  • Giải thích vấn đề. Nếu người đọc không biết vấn đề là gì và tại sao đó lại là một vấn đề, (họ) sẽ không thể giải quyết được.
  • Luôn đảm bảo người đọc có thể tái hiện vấn đề của bạn với ít công sức nhất có thể. Nếu đoạn mã của bạn không thể chạy do thiếu thư viện hoặc các biến chưa được định nghĩa, người đọc sẽ không thể giúp bạn. Hãy đảm bảo đoạn mã tái hiện được của bạn là tối giản nhất có thể và có thể sao chép, dán vào một shell Python đơn giản.
  • Nếu việc tái hiện vấn đề của bạn yêu cầu một mô hình và/hoặc bộ dữ liệu, hãy đảm bảo rằng người đọc có quyền truy cập vào mô hình hoặc bộ dữ liệu đó. Bạn luôn có thể tải mô hình hoặc bộ dữ liệu của mình lên Hub để việc tải xuống trở nên dễ dàng. Hãy cố gắng giữ mô hình và bộ dữ liệu của bạn nhỏ nhất có thể, để việc tái hiện vấn đề của bạn trở nên dễ dàng nhất có thể.

Để biết thêm thông tin, vui lòng xem phần Cách viết một issue tốt.

Bạn có thể mở báo lỗi tại đây.

2.2. Yêu cầu tính năng

Một yêu cầu tính năng đẳng cấp thế giới giải quyết các điểm sau:

  1. Trước hết là động lực:
  • Có liên quan đến vấn đề/khó khăn nào với thư viện không? Nếu có, vui lòng giải thích lý do. Tốt nhất là cung cấp một đoạn mã minh họa cho vấn đề đó.
  • Liệu điều này có liên quan đến thứ gì đó bạn cần cho một dự án không? Chúng tôi rất muốn nghe về điều đó!
  • Có phải đó là thứ bạn đã làm và nghĩ rằng có thể mang lại lợi ích cho cộng đồng không? Tuyệt vời! Hãy cho chúng tôi biết nó đã giải quyết vấn đề gì cho bạn.
  1. Viết một đoạn văn đầy đủ mô tả tính năng;
  2. Cung cấp một mảnh mã minh họa cách sử dụng trong tương lai;
  3. Nếu điều này liên quan đến một bài báo, vui lòng đính kèm liên kết;
  4. Đính kèm bất kỳ thông tin bổ sung nào (bản vẽ, ảnh chụp màn hình, v.v.) mà bạn cho là có thể hữu ích.

Bạn có thể mở một yêu cầu tính năng tại đây.

2.3 Phản hồi

Phản hồi về thiết kế thư viện và lý do tại sao thiết kế đó tốt hay không tốt sẽ hỗ trợ rất nhiều cho các nhà bảo trì cốt lõi trong việc xây dựng một thư viện thân thiện với người dùng. Để hiểu triết lý đằng sau triết lý thiết kế hiện tại, vui lòng xem ở đây. Nếu bạn cảm thấy một lựa chọn thiết kế nhất định không phù hợp với triết lý thiết kế hiện tại, vui lòng giải thích lý do và cách nên thay đổi. Nếu một lựa chọn thiết kế nhất định tuân thủ triết lý thiết kế quá chặt chẽ, do đó hạn chế các trường hợp sử dụng, hãy giải thích lý do và cách nên thay đổi. Nếu một lựa chọn thiết kế nhất định rất hữu ích cho bạn, vui lòng cũng để lại một ghi chú vì đây là phản hồi tuyệt vời cho các quyết định thiết kế trong tương lai.

Bạn có thể mở một issue về phản hồi tại đây.

2.4 Câu hỏi kỹ thuật

Các câu hỏi kỹ thuật chủ yếu liên quan đến lý do tại sao một phần mã nhất định của thư viện được viết theo cách cụ thể, hoặc một phần mã nhất định thực hiện chức năng gì. Vui lòng đảm bảo liên kết đến mã liên quan và cung cấp chi tiết về lý do tại sao phần mã này khó hiểu.

Bạn có thể mở một issue về câu hỏi kỹ thuật tại đây.

2.5 Đề xuất thêm một mô hình, bộ lập lịch hoặc đường ống mới

Nếu cộng đồng mô hình khuếch tán phát hành một mô hình, pipeline hoặc scheduler mới mà bạn muốn thấy trong thư viện Diffusers, vui lòng cung cấp các thông tin sau:

  • Mô tả ngắn gọn về pipeline khuếch tán, mô hình hoặc trình lập lịch, kèm liên kết đến bài báo hoặc bản phát hành công khai.
  • Liên kết đến bất kỳ bản triển khai mã nguồn mở nào của nó.
  • Liên kết đến trọng số mô hình nếu có sẵn.

Ngoài ra, đừng quên gắn thẻ tác giả gốc của thành phần (mô hình, trình lập lịch, đường ống, v.v.) bằng tên người dùng GitHub nếu bạn có thể tìm thấy.

Nếu bạn muốn tự đưa mô hình vào Diffusers, hãy xem Đăng tải pipeline hoặc mô hình lên Hub và Thêm pipeline, mô hình, scheduler.

Bạn có thể mở yêu cầu cho một model/pipeline/scheduler tại đây.

3. Trả lời các vấn đề trên tab GitHub issues

Việc trả lời các vấn đề trên GitHub có thể đòi hỏi một số kiến thức kỹ thuật về Diffusers, nhưng chúng tôi khuyến khích mọi người thử sức ngay cả khi bạn không hoàn toàn chắc chắn rằng câu trả lời của mình là chính xác. Một số mẹo để đưa ra câu trả lời chất lượng cao cho một vấn đề:

  • Hãy ngắn gọn và tối giản nhất có thể.
  • Giữ đúng chủ đề. Câu trả lời cho vấn đề phải liên quan đến vấn đề đó và chỉ vấn đề đó.
  • Cung cấp các liên kết đến mã nguồn, bài báo hoặc các nguồn khác để chứng minh hoặc củng cố quan điểm của bạn.
  • Trả lời bằng mã. Nếu một đoạn mã đơn giản là câu trả lời cho vấn đề hoặc cho thấy cách giải quyết vấn đề, vui lòng cung cấp một đoạn mã hoàn toàn có thể tái lập.

Ngoài ra, nhiều vấn đề thường chỉ đơn giản là lạc đề, trùng lặp với các vấn đề khác, hoặc không liên quan. Bạn sẽ hỗ trợ rất nhiều cho các nhà bảo trì nếu có thể trả lời các vấn đề như vậy, khuyến khích tác giả của vấn đề mô tả chính xác hơn, cung cấp liên kết đến vấn đề bị trùng lặp hoặc hướng họ đến GitHub Discussions hoặc Discord.

Nếu bạn đã xác minh rằng báo cáo lỗi được phát hành là chính xác và cần một sự sửa đổi trong mã nguồn, hãy xem các phần tiếp theo.

Đối với tất cả các đóng góp, ngoại trừ 6, bạn cần mở một PR. Mục Opening a pull request giải thích cách thực hiện.

4. Sửa một “Good first issue”

Các vấn đề phù hợp cho người mới được đánh dấu bằng nhãn Good first issue. Thông thường, vấn đề đã mô tả cách một giải pháp tiềm năng nên trông như thế nào để việc khắc phục dễ dàng hơn. Nếu vấn đề chưa được đóng và bạn muốn thử khắc phục, bạn chỉ cần để lại một tin nhắn “I would like to try this issue.”. Thông thường có ba kịch bản:

  • a.) Mô tả vấn đề đã đề xuất một cách sửa. Trong trường hợp này và nếu giải pháp có ý nghĩa với bạn, bạn có thể mở một PR hoặc PR nháp để sửa nó.
  • b.) Mô tả vấn đề không đề xuất cách khắc phục. Trong trường hợp này, hãy tự đề xuất cách khắc phục trong một bình luận trên issue. Một vài câu mô tả cách tiếp cận là đủ. Chờ đến khi có ai đó từ nhóm Diffusers xác nhận trước khi bạn mở PR.
  • c.) Đã có một PR mở để sửa lỗi, nhưng lỗi vẫn chưa được đóng. Nếu PR đã bị bỏ quên, bạn có thể đơn giản mở một PR mới và liên kết đến PR bị bỏ quên đó. Các PR thường bị bỏ quên khi người đóng góp ban đầu muốn sửa lỗi đột nhiên không còn thời gian để tiếp tục. Điều này thường xảy ra trong mã nguồn mở và hoàn toàn bình thường. Trong trường hợp này, cộng đồng sẽ rất vui nếu bạn thử lại và tận dụng kiến thức từ PR hiện có. Nếu đã có một PR và nó đang hoạt động, bạn có thể hỗ trợ tác giả bằng cách đưa ra gợi ý, xem xét PR hoặc thậm chí hỏi xem bạn có thể đóng góp vào PR đó không.

5. Đóng góp cho tài liệu

Một thư viện tốt luôn có tài liệu tốt! Tài liệu chính thức thường là một trong những điểm tiếp xúc đầu tiên của người dùng mới với thư viện, do đó đóng góp cho tài liệu là một đóng góp vô cùng giá trị.

Việc đóng góp cho thư viện có thể có nhiều hình thức:

  • Sửa các lỗi chính tả hoặc ngữ pháp.
  • Sửa định dạng không chính xác của docstring. Nếu bạn thấy tài liệu chính thức hiển thị sai lệch hoặc một liên kết bị hỏng, chúng tôi sẽ rất vui nếu bạn dành chút thời gian để sửa chữa.
  • Sửa lại hình dạng hoặc số chiều của tensor đầu vào hoặc đầu ra trong docstring.
  • Làm rõ tài liệu khó hiểu hoặc không chính xác.
  • Cập nhật các ví dụ mã cũ.
  • Dịch tài liệu sang một ngôn ngữ khác.

Bất kỳ nội dung nào được hiển thị trên trang tài liệu chính thức của Diffusers đều là một phần của tài liệu chính thức và có thể được sửa đổi, điều chỉnh trong nguồn tài liệu tương ứng.

Hãy xem trang này để biết cách kiểm tra các thay đổi đã thực hiện đối với tài liệu cục bộ.

6. Công bố một pipeline hoặc model trên Hub

Với Modular Diffusers, một pipeline có thể tồn tại dưới dạng mã từ xa trong bất kỳ kho Hub nào. Bất kỳ ai cũng có thể tải nó bằng from_pretrained(..., trust_remote_code=True), mà không cần chờ một bản phát hành Diffusers. Nếu bạn là một người đóng góp cho cộng đồng đang mang đến một pipeline hoặc model mới, hãy bắt đầu từ đây. Xem custom blocks để phát hành một pipeline và custom models để phát hành một model.

Hãy cho chúng tôi biết dưới yêu cầu mô hình tương ứng (mở một yêu cầu mới nếu chưa có): chúng tôi sẽ phản hồi về việc triển khai và giới thiệu những mô hình mà chúng tôi đánh giá cao trong bộ sưu tập Community Modular Diffusers Blocks của mình. Từ đó, chúng tôi sẽ quyết định cách hỗ trợ mô hình trong thư viện: chúng tôi có thể đưa phiên bản của bạn lên upstream, làm việc với các tác giả để tạo ra một phiên bản chính thức, hoặc đơn giản là hướng mọi người đến phiên bản của bạn. Hãy cho chúng tôi biết những điểm gây khó khăn mà bạn gặp phải trong quá trình này: API gây nhầm lẫn, tài liệu thiếu sót, lỗi. Phản hồi đó có giá trị ngang với pipeline đối với chúng tôi.

7. Đóng góp cho các ví dụ huấn luyện

Các ví dụ Diffusers là một tập hợp các script huấn luyện nằm trong examples.

Chúng tôi hỗ trợ hai loại ví dụ huấn luyện:

  • Ví dụ huấn luyện chính thức
  • Nghiên cứu các ví dụ huấn luyện

Các ví dụ huấn luyện nghiên cứu nằm trong examples/research_projects trong khi các ví dụ huấn luyện chính thức bao gồm tất cả các thư mục dưới examples ngoại trừ các thư mục research_projects và community. Các ví dụ huấn luyện chính thức được duy trì bởi các nhà duy trì cốt lõi của Diffusers trong khi các ví dụ huấn luyện nghiên cứu được duy trì bởi cộng đồng. Điều này cũng giống như lý do thư viện giữ một bộ nhỏ các pipeline chính thức và pipeline cộng đồng hoạt động trên Hub: không khả thi để các nhà duy trì cốt lõi duy trì tất cả các phương pháp huấn luyện có thể có cho các mô hình khuếch tán. Nếu các nhà duy trì cốt lõi của Diffusers và cộng đồng coi một hệ thống huấn luyện nhất định là quá thử nghiệm hoặc chưa đủ phổ biến, mã huấn luyện tương ứng nên được đặt trong thư mục research_projects và được duy trì bởi tác giả.

Cả các ví dụ huấn luyện chính thức lẫn ví dụ nghiên cứu đều bao gồm một thư mục chứa một hoặc nhiều script huấn luyện, tệp requirements.txt và tệp README.md. Để người dùng có thể sử dụng các ví dụ huấn luyện, cần phải clone kho mã:

git clone https://github.com/huggingface/diffusers

cũng như cài đặt tất cả các phụ thuộc bổ sung cần thiết cho việc huấn luyện:

cd diffusers
pip install -r examples/<your-example-folder>/requirements.txt

Do đó, khi thêm một ví dụ, tệp requirements.txt phải định nghĩa tất cả các phụ thuộc pip cần thiết cho ví dụ huấn luyện của bạn để sau khi cài đặt tất cả, người dùng có thể chạy script huấn luyện của ví dụ đó. Xem, ví dụ, tệp DreamBooth requirements.txt.

Các ví dụ huấn luyện của thư viện Diffusers nên tuân theo triết lý sau:

  • Toàn bộ mã cần thiết để chạy các ví dụ nên được đặt trong một tệp Python duy nhất.
  • Người dùng phải có thể chạy ví dụ từ dòng lệnh bằng python <your-example>.py --args.
  • Các ví dụ nên được giữ đơn giản và đóng vai trò là một ví dụ về cách sử dụng Diffusers để huấn luyện. Mục đích của các script ví dụ là không phải để tạo ra các mô hình khuếch tán tiên tiến nhất, mà là tái hiện các phương pháp huấn luyện đã biết mà không thêm quá nhiều logic tùy chỉnh. Là một hệ quả của điểm này, các ví dụ của chúng tôi cũng nỗ lực đóng vai trò là tài liệu giáo dục tốt.

Để đóng góp một ví dụ, rất khuyến khích bạn tham khảo các ví dụ hiện có như dreambooth để có ý tưởng về cách chúng nên được trình bày. Chúng tôi khuyên mạnh mẽ các nhà đóng góp nên sử dụng Accelerate library vì nó được tích hợp chặt chẽ với Diffusers. Khi một script ví dụ hoạt động, vui lòng đảm bảo thêm một README.md đầy đủ mô tả chính xác cách sử dụng ví dụ. README này nên bao gồm:

  • Một lệnh ví dụ về cách chạy script mẫu như được hiển thị tại đây.
  • Một liên kết đến một số kết quả huấn luyện (nhật ký, mô hình, v.v.) cho thấy những gì người dùng có thể kỳ vọng như đã hiển thị tại đây.
  • Nếu bạn đang thêm một ví dụ huấn luyện không chính thức/nghiên cứu, đừng quên thêm một câu xác nhận rằng bạn đang duy trì ví dụ huấn luyện này, bao gồm tên người dùng git của bạn như được hiển thị tại đây.

Nếu bạn đóng góp cho các ví dụ huấn luyện chính thức, vui lòng đảm bảo thêm một bài kiểm tra vào thư mục của nó, chẳng hạn như examples/dreambooth/test_dreambooth.py. Điều này không cần thiết đối với các ví dụ huấn luyện không chính thức.

8. Sửa một “Vấn đề thứ hai tốt”

Các vấn đề tốt cho lần thứ hai được đánh dấu bằng nhãn Good second issue. Chúng thường phức tạp hơn để giải quyết so với Các vấn đề tốt cho lần đầu, mô tả cung cấp ít hướng dẫn hơn về cách sửa, và đòi hỏi sự hiểu biết nhất định về thư viện.

Nếu bạn quan tâm đến việc xử lý một issue thứ hai tốt, hãy chia sẻ quan điểm của bạn về issue và cách tiếp cận bạn đang dự định dưới dạng bình luận, trong vài câu, và nhận được sự xác nhận từ một maintainer trước khi bạn mở PR. Nếu một PR đã được mở cho issue nhưng chưa được merge, hãy xem xét để hiểu lý do tại sao trước khi bạn đề xuất điều gì đó mới.

9. Giải quyết một vấn đề MVP của Diffusers

Chương trình Diffusers MVP liệt kê các vấn đề mà chúng tôi cần hỗ trợ nhất. Chúng hoạt động giống như các vấn đề Good second, nhưng khó hơn và tốn nhiều thời gian hơn, và chương trình sẽ phần thưởng cho những người đóng góp nhận xử lý chúng. Hãy chia sẻ cách tiếp cận của bạn dưới dạng bình luận trước và nhận được sự xác nhận từ một người duy trì trước khi bạn mở PR. Chương trình cũng có một lộ trình ý tưởng: hãy cho chúng tôi biết một ý tưởng sẽ làm tăng tác động của Diffusers, trong vài câu và không có chi tiết triển khai.

10. Thêm các pipeline, mô hình, trình lập lịch

Nếu bạn là tác giả của mô hình, vui lòng liên hệ để chúng tôi có thể phối hợp tích hợp với bạn: mở một yêu cầu tính năng, hoặc để lại bình luận nếu đã có yêu cầu nào đang mở.

Nếu bạn là người đóng góp cho cộng đồng, hãy bắt đầu với một kho Hub trước, xem Đăng tải pipeline hoặc model lên Hub, và cho chúng tôi biết dưới yêu cầu tính năng rằng bạn quan tâm đến việc đưa nó lên upstream.

Pipelines, models và schedulers là những thành phần quan trọng nhất của thư viện Diffusers. Chúng cung cấp khả năng truy cập dễ dàng vào các công nghệ diffusion tiên tiến, từ đó cho phép cộng đồng xây dựng các ứng dụng AI tạo sinh mạnh mẽ.

Việc thêm một mô hình, pipeline hoặc scheduler mới có thể mở ra một trường hợp sử dụng mạnh mẽ mới cho bất kỳ giao diện người dùng nào dựa trên Diffusers, từ đó mang lại giá trị to lớn cho toàn bộ hệ sinh thái AI tạo sinh.

Khi có hỗ trợ cho mô hình hoặc pipeline mới

Một mô hình hoặc pipeline mới có thể được đưa vào một bản phát hành nếu bạn phối hợp tích hợp với nhóm Diffusers trước đó. Hãy liên hệ với chúng tôi, thông qua một issue trên kho Diffusers hoặc bằng cách gửi email đến [email protected].

Một bản phát hành sẽ không được thực hiện tự động khi một pull request cho model hoặc pipeline được hợp nhất. Trước khi phát hành, các maintainer trước tiên sẽ kiểm tra rằng tích hợp đã hoàn tất và các bài kiểm tra phát hành đạt yêu cầu.

Hỗ trợ cho mô hình hoặc pipeline mới thường được đưa vào bản phát hành phụ (minor release) tiếp theo. Việc tích hợp được hợp nhất vào main và nhánh phát hành được tạo từ đó. Bản phát hành bao gồm tất cả các thay đổi được hợp nhất kể từ bản phát hành trước, chứ không chỉ riêng việc tích hợp mô hình hoặc pipeline.

Ghi chú phát hành làm nổi bật mô hình hoặc pipeline mới và cũng tóm tắt các thay đổi khác được bao gồm trong bản phát hành. Các bản phát hành vá thường được dành riêng cho việc sửa lỗi trong một bản phát hành hiện có.

Diffusers có một vài yêu cầu tính năng đang mở cho cả ba thành phần - bạn có thể lướt qua chúng nếu chưa biết chính xác thành phần nào mình muốn thêm:

Trước khi thêm bất kỳ thành phần nào trong ba thành phần, chúng tôi rất khuyến khích bạn đọc Philosophy guide để hiểu rõ hơn về thiết kế của từng thành phần. Vui lòng lưu ý rằng chúng tôi không thể hợp nhất các bổ sung về model, scheduler hoặc pipeline nếu chúng khác biệt đáng kể so với triết lý thiết kế của chúng tôi, vì điều đó sẽ dẫn đến sự không nhất quán trong API. Nếu bạn hoàn toàn không đồng ý với một lựa chọn thiết kế, vui lòng mở một Feedback issue để thảo luận xem liệu một mẫu thiết kế/lựa chọn thiết kế cụ thể có nên được thay đổi ở mọi nơi trong thư viện hay không và liệu chúng tôi có nên cập nhật triết lý thiết kế của mình hay không. Sự nhất quán xuyên suốt thư viện là rất quan trọng đối với chúng tôi.

Hãy đảm bảo thêm liên kết đến mã nguồn gốc/bài báo gốc vào PR và lý tưởng nhất là cũng ping trực tiếp tác giả gốc trên PR để họ có thể theo dõi tiến độ và có thể hỗ trợ trả lời các câu hỏi.

Nếu bạn không chắc chắn hoặc đang gặp khó khăn trong PR, đừng ngần ngại để lại tin nhắn để yêu cầu xem xét ban đầu hoặc hỗ trợ.

Được sao chép từ cơ chế

Một tính năng độc đáo và quan trọng cần nắm vững khi thêm bất kỳ mã pipeline, model hay scheduler nào là cơ chế # Copied from. Bạn sẽ thấy cơ chế này xuất hiện khắp nơi trong codebase của Diffusers, và lý do chúng tôi sử dụng nó là để giữ cho codebase dễ hiểu và dễ bảo trì. Việc đánh dấu mã bằng cơ chế # Copied from buộc mã được đánh dấu phải giống hệt với mã mà nó được sao chép từ đó. Điều này giúp việc cập nhật và lan truyền các thay đổi qua nhiều tệp trở nên dễ dàng mỗi khi bạn chạy make fix-copies.

Ví dụ, trong đoạn mã dưới đây, StableDiffusionPipelineOutput là mã gốc và AltDiffusionPipelineOutput sử dụng cơ chế # Copied from để sao chép nó. Điểm khác biệt duy nhất là thay đổi tiền tố lớp từ Stable thành Alt.

# Copied from diffusers.pipelines.stable_diffusion.pipeline_output.StableDiffusionPipelineOutput with Stable->Alt
class AltDiffusionPipelineOutput(BaseOutput):
    """
    Output class for Alt Diffusion pipelines.

    Args:
        images (`List[PIL.Image.Image]` or `np.ndarray`)
            List of denoised PIL images of length `batch_size` or NumPy array of shape `(batch_size, height, width,
            num_channels)`.
        nsfw_content_detected (`List[bool]`)
            List indicating whether the corresponding generated image contains "not-safe-for-work" (nsfw) content or
            `None` if safety checking could not be performed.
    """

Để tìm hiểu thêm, hãy đọc phần này của bài đăng trên blog ~Đừng~ Lặp Lại Bản Thân*.

Cách viết một issue tốt

Issue của bạn được viết càng chi tiết, khả năng được giải quyết nhanh chóng càng cao.

  1. Hãy đảm bảo rằng bạn đã sử dụng đúng mẫu cho vấn đề của mình. Bạn có thể chọn giữa Báo cáo lỗi, Yêu cầu tính năng, Phản hồi về thiết kế API, Thêm model/pipeline/scheduler mới, hoặc một issue trống. Hãy chắc chắn chọn đúng mẫu khi mở một issue mới. Các câu hỏi về cách sử dụng nên được đặt trong GitHub Discussions, không phải trong một issue.
  2. Chính xác: Đặt tiêu đề phù hợp cho vấn đề của bạn. Cố gắng diễn đạt mô tả vấn đề đơn giản nhất có thể. Bạn càng chính xác khi gửi vấn đề, thời gian để hiểu và có thể giải quyết vấn đề càng ngắn. Hãy đảm bảo chỉ mở một issue cho một vấn đề duy nhất, không mở cho nhiều vấn đề. Nếu bạn phát hiện nhiều vấn đề, hãy mở nhiều issue tương ứng. Nếu vấn đề của bạn là lỗi, hãy cố gắng chính xác nhất có thể về lỗi đó - bạn không nên chỉ viết “Error in diffusers”.
  3. Tính tái lập: Không có đoạn mã tái lập được == không có giải pháp. Nếu bạn gặp lỗi, người duy trì phải có khả năng tái lập lỗi đó. Hãy đảm bảo bạn bao gồm một đoạn mã có thể sao chép và dán vào trình thông dịch Python để tái lập vấn đề. Hãy đảm bảo đoạn mã của bạn hoạt động, tức là không thiếu import hay thiếu liên kết đến hình ảnh, … Vấn đề của bạn phải chứa thông báo lỗi và một đoạn mã có thể sao chép và dán mà không cần thay đổi để tái lập chính xác cùng thông báo lỗi đó. Nếu vấn đề của bạn sử dụng trọng số mô hình cục bộ hoặc dữ liệu cục bộ mà người đọc không thể truy cập, vấn đề đó không thể được giải quyết. Nếu bạn không thể chia sẻ dữ liệu hoặc mô hình của mình, hãy cố gắng tạo một mô hình giả lập hoặc dữ liệu giả lập.
  4. Tối giản: Hãy cố gắng hỗ trợ người đọc hiểu vấn đề nhanh nhất có thể bằng cách giữ nội dung ngắn gọn nhất có thể. Loại bỏ tất cả mã / tất cả thông tin không liên quan đến vấn đề. Nếu bạn đã tìm thấy một lỗi, hãy cố gắng tạo ví dụ mã đơn giản nhất có thể để minh họa vấn đề của bạn, đừng chỉ đổ toàn bộ quy trình làm việc của bạn vào vấn đề ngay khi bạn tìm thấy lỗi. Ví dụ, nếu bạn huấn luyện một mô hình và gặp lỗi ở một điểm nào đó trong quá trình huấn luyện, bạn nên trước tiên cố gắng hiểu phần nào của mã huấn luyện chịu trách nhiệm cho lỗi và cố gắng tái hiện nó với vài dòng. Hãy cố gắng sử dụng dữ liệu giả thay vì bộ dữ liệu đầy đủ.
  5. Bối cảnh: Hãy cho chúng tôi biết bạn đang làm gì khi gặp lỗi hoặc cần tính năng, chẳng hạn như một ứng dụng được xây dựng trên Diffusers, một dự án nghiên cứu, hoặc một agent bạn đã chạy để tìm lỗi trong thư viện. Một hoặc hai câu là đủ, và một liên kết đến dự án sẽ rất hữu ích. Chúng tôi nhận được nhiều issue và PR hơn số lượng có thể xử lý cùng lúc, nên bối cảnh giúp chúng tôi ưu tiên theo mức độ tác động.
  6. Thêm liên kết. Nếu bạn đề cập đến một cách đặt tên, phương pháp hoặc mô hình cụ thể, hãy đảm bảo cung cấp liên kết để người đọc hiểu rõ hơn ý của bạn. Nếu bạn đề cập đến một PR hoặc issue cụ thể, hãy đảm bảo liên kết nó với issue của bạn. Đừng giả định rằng người đọc biết bạn đang nói về điều gì. Càng thêm nhiều liên kết vào issue của bạn thì càng tốt.
  7. Định dạng. Hãy đảm bảo định dạng vấn đề của bạn một cách rõ ràng bằng cách định dạng mã thành cú pháp mã Python và thông báo lỗi thành cú pháp mã thông thường. Xem tài liệu định dạng chính thức của GitHub để biết thêm thông tin.
  8. Hãy xem vấn đề của bạn không phải là một ticket cần được giải quyết, mà là một mục nhập đẹp đẽ trong một cuốn bách khoa toàn thư được viết kỹ lưỡng. Mỗi issue được thêm vào đều là một đóng góp cho tri thức công khai. Bằng cách thêm một issue được viết chỉn chu, bạn không chỉ giúp các maintainer giải quyết vấn đề của bạn dễ dàng hơn, mà còn hỗ trợ toàn bộ cộng đồng hiểu rõ hơn về một khía cạnh nhất định của thư viện.

Cách viết một PR tốt

  1. Luôn bắt đầu từ một issue. Hãy tìm issue mà pull request của bạn giải quyết, hoặc mở một issue mới nếu chưa ai làm, và cho phép các maintainer có cơ hội phản hồi trước khi bạn viết code. Quy trình hoạt động tốt nhất cho chúng tôi là mở một issue, sau đó thảo luận về giải pháp, rồi tạo PR dựa trên cuộc thảo luận đó. Cách này giúp chúng tôi tập trung thời gian vào những issue có tác động lớn nhất, thống nhất phạm vi trước khi code tồn tại, và tránh làm việc trùng lặp. Hãy đề cập số issue trong mô tả PR (ví dụ: Fixes #1234) để liên kết hai bên.
  2. Hãy trở thành một con tắc kè. Hãy hiểu các mẫu thiết kế và cú pháp hiện có, đảm bảo rằng các phần mã bạn thêm vào hòa hợp một cách liền mạch với mã nguồn hiện tại. Các yêu cầu kéo (pull request) có sự khác biệt đáng kể so với các mẫu thiết kế hoặc giao diện người dùng hiện có sẽ không được hợp nhất.
  3. Hãy tập trung cao độ. Một pull request nên giải quyết một vấn đề và chỉ một vấn đề. Hãy đảm bảo không sa vào bẫy “cùng lúc sửa thêm một vấn đề khác khi đang thêm tính năng này”. Việc xem xét các pull request giải quyết nhiều vấn đề không liên quan cùng một lúc sẽ khó khăn hơn rất nhiều.
  4. Sửa các mẫu lỗi, không chỉ những trường hợp đơn lẻ. Một vấn đề có thể trải dài qua nhiều tệp: nếu cùng một lỗi lặp lại trong toàn bộ mã nguồn, hãy tìm kiếm mọi trường hợp và sửa tất cả chúng trong một PR duy nhất với phạm vi rõ ràng, có hệ thống (ví dụ: “sửa các giá trị mặc định có thể thay đổi trong tất cả các scheduler”), thay vì một PR cho từng trường hợp.
  5. Tiêu đề của pull request của bạn nên là một bản tóm tắt về đóng góp của nó. Để chỉ ra rằng đây là một công việc đang được thực hiện, hãy thêm tiền tố [WIP] vào tiêu đề; điều này giúp tránh việc làm trùng lặp và tách biệt PR này khỏi các PR đã sẵn sàng để hợp nhất.
  6. Hãy cố gắng xây dựng và định dạng văn bản của bạn như đã mô tả trong Cách viết một issue tốt.
  7. Xem lại diff của chính bạn trước khi mở PR. Đọc nó như một người review và sửa những gì bạn phát hiện. Chúng tôi rất khuyến khích chạy kỹ năng self-review: nó chạy cùng bộ tiêu chí đánh giá với người review CI @claude. Thiết lập agent của bạn như mô tả trong Coding with AI agents và làm theo AI-assisted and agentic contributions. Trong phần mô tả, hãy nêu rõ những phát hiện mà bạn chủ ý giữ nguyên, để người review biết đó là một quyết định chứ không phải sự bỏ sót.
  8. Đảm bảo các bài kiểm tra hiện có chạy thành công.
  9. Thêm các bài kiểm tra có độ bao phủ cao. Không có kiểm tra chất lượng = không được hợp nhất.
  • Nếu bạn đang thêm các bài kiểm tra @slow mới, hãy đảm bảo chúng đạt yêu cầu bằng cách chạy RUN_SLOW=1 python -m pytest tests/test_my_new_model.py. CircleCI không chạy các bài kiểm tra chậm, nhưng GitHub Actions thì chạy mỗi đêm!
  1. Tất cả các phương thức công khai phải có docstring mang tính thông tin và hiển thị tốt với markdown. Xem pipeline_latent_diffusion.py để có ví dụ.
  2. Do kho lưu trữ đang phát triển nhanh chóng, việc đảm bảo không thêm các tệp làm tăng đáng kể dung lượng kho là rất quan trọng. Điều này bao gồm hình ảnh, video và các tệp không phải văn bản khác. Chúng tôi ưu tiên sử dụng dataset được lưu trữ trên hf.co như hf-internal-testing hoặc huggingface/documentation-images để đặt các tệp này. Nếu đây là đóng góp từ bên ngoài, bạn có thể thêm hình ảnh vào PR của mình và yêu cầu một thành viên của Hugging Face di chuyển hình ảnh của bạn sang dataset này.

Cách mở một PR

Trước khi viết mã, chúng tôi khuyên bạn nên tìm kiếm trong các PR hoặc issue hiện có để đảm bảo rằng không ai đang làm cùng một thứ. Nếu bạn không chắc chắn, việc mở một issue để nhận phản hồi luôn là một ý tưởng hay.

Bạn cần có kiến thức cơ bản về git để có thể đóng góp cho 🧨 Diffusers. git không phải là công cụ dễ sử dụng nhất nhưng nó có tài liệu hướng dẫn tuyệt vời nhất. Gõ git --help trong shell và tận hưởng. Nếu bạn thích sách, Pro Git là một tài liệu tham khảo rất tốt.

Thực hiện các bước sau để bắt đầu đóng góp (các phiên bản Python được hỗ trợ):

  1. Fork repository bằng cách nhấp vào nút ‘Fork’ trên trang của repository. Thao tác này tạo ra một bản sao của mã nguồn dưới tài khoản GitHub của bạn.

  2. Clone bản fork của bạn về ổ đĩa cục bộ và thêm kho cơ sở dưới dạng remote:

    $ git clone [email protected]:<your GitHub handle>/diffusers.git
$ cd diffusers
$ git remote add upstream https://github.com/huggingface/diffusers.git

  3. Tạo một nhánh mới để lưu các thay đổi phát triển của bạn:

    $ git checkout -b a-descriptive-name-for-my-changes

Không làm việc trên nhánh main.

  1. Cài đặt môi trường phát triển bằng cách chạy lệnh sau trong một môi trường ảo:

    $ pip install -e ".[dev]"

Nếu bạn đã clone repo, bạn có thể cần chạy git pull để lấy những thay đổi mới nhất trong thư viện.

  1. Phát triển các tính năng trên nhánh của bạn.

Khi làm việc với các tính năng, bạn cần đảm bảo rằng bộ kiểm thử (test suite) chạy thành công. Bạn nên chạy các bài kiểm thử bị ảnh hưởng bởi những thay đổi của mình như sau:

$ pytest tests/<TEST_TO_RUN>.py

Trước khi chạy các bài kiểm tra, hãy đảm bảo bạn đã cài đặt các phụ thuộc cần thiết cho việc kiểm thử. Bạn có thể thực hiện điều này bằng lệnh sau:

$ pip install -e ".[test]"

Bạn cũng có thể chạy bộ kiểm thử đầy đủ bằng lệnh sau, nhưng hiện tại cần một máy cấu hình mạnh để có kết quả trong thời gian hợp lý vì Diffusers đã phát triển rất nhiều. Lệnh như sau:

$ make test

🧨 Diffusers dựa vào black và isort để định dạng mã nguồn một cách nhất quán. Sau khi bạn thực hiện các thay đổi, hãy áp dụng các sửa lỗi tự động về phong cách và xác minh mã không thể tự động hóa bằng một lần chạy:

$ make style

🧨 Diffusers cũng sử dụng ruff và một số script tùy chỉnh để kiểm tra lỗi lập trình. Kiểm soát chất lượng được chạy trong CI, tuy nhiên, bạn cũng có thể chạy các kiểm tra tương tự bằng cách:

$ make quality

Khi bạn đã hài lòng với các thay đổi, hãy thêm các tệp đã thay đổi bằng git add và tạo một commit bằng git commit để ghi lại các thay đổi của bạn cục bộ:

$ git add modified_file.py
$ git commit -m "A descriptive message about your changes."

Việc đồng bộ hóa bản sao mã nguồn của bạn với kho lưu trữ gốc thường xuyên là một ý tưởng hay. Bằng cách này, bạn có thể nhanh chóng xử lý các thay đổi:

$ git pull upstream main

Đẩy các thay đổi lên tài khoản của bạn bằng cách sử dụng:

$ git push -u origin a-descriptive-name-for-my-changes

  1. Khi bạn đã hài lòng, hãy truy cập trang web của bản fork dự án của bạn trên GitHub. Nhấp vào ‘Pull request’ để gửi các thay đổi của bạn cho các người duy trì dự án để xem xét.

  2. Việc các nhà bảo trì yêu cầu bạn thực hiện các thay đổi là hoàn toàn bình thường. Ngay cả các nhà đóng góp cốt lõi cũng gặp tình huống này! Để mọi người có thể xem các thay đổi trong Pull request, hãy làm việc trên nhánh cục bộ của bạn và đẩy các thay đổi lên fork của bạn. Chúng sẽ tự động xuất hiện trong pull request.

Kiểm thử

Bộ kiểm thử toàn diện được bao gồm để kiểm tra hành vi của thư viện và một số ví dụ. Các bài kiểm tra thư viện có thể được tìm thấy trong thư mục tests.

Chúng tôi thích pytest và pytest-xdist vì chúng nhanh hơn. Từ thư mục gốc của repository, đây là cách chạy các bài kiểm thử bằng pytest cho thư viện:

$ python -m pytest -n auto --dist=loadfile -s -v ./tests/

Thực tế, đó chính là cách make test được triển khai!

Bạn có thể chỉ định một bộ kiểm tra nhỏ hơn để chỉ kiểm tra tính năng mà bạn đang làm việc.

Mặc định, các bài kiểm tra chậm sẽ bị bỏ qua. Đặt biến môi trường RUN_SLOW thành yes để chạy chúng. Thao tác này sẽ tải xuống nhiều gigabyte mô hình — hãy đảm bảo bạn có đủ dung lượng ổ đĩa và kết nối Internet tốt, hoặc nhiều kiên nhẫn!

$ RUN_SLOW=yes python -m pytest -n auto --dist=loadfile -s -v ./tests/

unittest được hỗ trợ đầy đủ, đây là cách chạy các bài kiểm thử bằng nó:

$ python -m unittest discover -s tests -t . -v
$ python -m unittest discover -s examples -t examples -v

Đồng bộ nhánh main đã fork với main của upstream (HuggingFace)

Để tránh việc gửi thông báo đến kho lưu trữ gốc, điều này sẽ thêm ghi chú tham chiếu vào mỗi PR của kho gốc và gửi các thông báo không cần thiết đến các nhà phát triển liên quan đến những PR này, khi đồng bộ nhánh chính của một kho lưu trữ đã fork, vui lòng thực hiện các bước sau:

  1. Khi có thể, hãy tránh đồng bộ hóa với upstream bằng cách sử dụng branch và PR trên kho lưu trữ đã fork. Thay vào đó, hãy merge trực tiếp vào main của kho lưu trữ đã fork.
  2. Nếu PR là hoàn toàn cần thiết, hãy sử dụng các bước sau sau khi kiểm tra ra nhánh của bạn:
$ git checkout -b your-branch-for-syncing
$ git pull --squash --no-commit upstream main
$ git commit -m '<your message without GitHub references>'
$ git push --set-upstream origin your-branch-for-syncing

Hướng dẫn về phong cách

Đối với chuỗi tài liệu, 🧨 Diffusers tuân theo phong cách Google.

Lập trình với các tác nhân AI

Kho lưu trữ giữ cấu hình AI-agent trong .ai/, đồng thời được phát hành dưới dạng plugin agent để cài đặt các kỹ năng tác vụ theo yêu cầu chỉ trong một bước.

  • Chỉ đọc cho người đóng góp — .ai/ được duy trì bởi các maintainer cốt lõi. Vui lòng không chỉnh sửa các tệp dưới .ai/ (hoặc các symlink AGENTS.md / CLAUDE.md ở cấp gốc, hoặc .agents/skills / .claude/skills đã được cài đặt) trong PR của bạn. Nếu bạn phát hiện điều gì đó bị thiếu hoặc sai, hãy mở một issue hoặc chỉ ra trong PR và một maintainer sẽ cập nhật.
  • Guidelines — .ai/AGENTS.md được nạp vào mọi phiên agent thông qua các symlink gốc AGENTS.md / CLAUDE.md ; các hướng dẫn tham chiếu dưới .ai/references/ được đọc theo yêu cầu khi một liên kết được truy cập:
  • Skills (dưới .ai/skills/, được tải theo yêu cầu cho các tác vụ cụ thể):
    • model-integration — thêm một mô hình hoặc pipeline mới vào diffusers một cách toàn diện (cấu trúc tệp, danh sách kiểm tra tích hợp, bố cục kiểm thử, chuyển đổi trọng số)
    • self-review — xem xét các thay đổi của bạn so với các quy tắc của dự án trước khi mở PR
    • diffusers-cli — chạy các pipeline và kiểm tra schema từ terminal
    • custom-blocks — đóng gói một lớp con của ModularPipelineBlocks cho Hub

Dù bạn chọn cách nào, hãy yêu cầu agent của bạn xác nhận cấu hình của nó trước khi bắt đầu — python utils/check_ai.py kiểm tra xem các hướng dẫn và kỹ năng có nhất quán không, còn diffusers-cli skills list hiển thị các kỹ năng mà nó thực sự có.

Đóng góp có sự hỗ trợ của AI và các tác nhân

Các AI agent được chào đón để đóng góp cho Diffusers. Chúng tôi khuyến khích bạn thiết lập agent của mình với hướng dẫn agent của Diffusers và sử dụng các kỹ năng cụ thể cho từng tác vụ liên quan, chẳng hạn như model-integration và self-review. Cài đặt plugin (hoặc các kỹ năng riêng lẻ) như đã mô tả ở trên, sau đó làm theo hướng dẫn để xác định phạm vi, triển khai, kiểm thử và xem xét đóng góp của bạn. Bạn vẫn chịu trách nhiệm về việc hiểu, kiểm thử và duy trì các thay đổi trong PR của mình.

Các đóng góp có sự hỗ trợ của AI được hoan nghênh, nhưng chúng phải được phối hợp, xác định phạm vi và kiểm tra để giữ cho khối lượng xem xét ở mức có thể quản lý. Các PR không tuân theo các hướng dẫn này có thể bị đóng mà không cần xem xét chi tiết.

  • Thỏa thuận trước khi mở PR. Tìm hoặc mở một issue, xem xét các PR tương tự (đang mở và vừa đóng), và chờ xác nhận rõ ràng từ một maintainer trên issue đó trước khi mở PR. Điều này giúp chúng tôi có cơ hội thảo luận về phạm vi, tránh làm việc trùng lặp và xác nhận phương pháp tiếp cận.
  • Sửa các mẫu lỗi, không phải từng trường hợp riêng lẻ. Nếu bạn phát hiện một vấn đề lặp lại, hãy tìm kiếm các trường hợp tương tự trong codebase và mở một issue duy nhất với phạm vi rõ ràng, có hệ thống (ví dụ: “sửa các giá trị mặc định có thể thay đổi trong tất cả các scheduler”) thay vì mở nhiều issue hoặc PR cho từng trường hợp riêng lẻ.
  • Tự kiểm tra trước khi mở. Chạy kỹ năng self-review — nó xem xét diff của bạn dựa trên .ai/references/review-rules.md, cùng bộ tiêu chí mà trình xem xét CI @claude sử dụng — và xử lý những gì nó báo cáo — đây là công cụ hỗ trợ, không phải nguồn chính thống, và có thể sai. Tập trung vào các vấn đề chặn hợp lý mà bạn thấy đúng, và dọn dẹp mã chết/không sử dụng càng nhiều càng tốt. Nếu bạn không đồng ý với một gợi ý, bạn có thể để lại cho trình xem xét thảo luận sau khi PR được mở — các ghi chú bạn chia sẻ (xem bên dưới) sẽ cho trình xem xét biết đó là một quyết định có chủ đích.
  • Chia sẻ ghi chú tự đánh giá của bạn. Vui lòng đăng báo cáo tự đánh giá cuối cùng — vòng phản ánh diff bạn đang gửi — lên PR, trong phần mô tả hoặc dưới dạng bình luận, bao gồm các phát hiện mà bạn cố ý không sửa và lý do. Điều này giúp người đánh giá thấy những gì đã được kiểm tra và những quyết định nào là có chủ đích, thường giúp tiết kiệm vài vòng trao đổi qua lại.
  • Giữ thông tin liên lạc trong PR của bạn ngắn gọn. Mọi thứ mà người xem xét đọc trong PR của bạn — mô tả, thông điệp commit, bình luận và phản hồi, chú thích trong mã — phải dễ hiểu cho con người. Nếu tác tử (agent) đã soạn thảo, đừng chỉ lướt qua. Hãy đọc kỹ và yêu cầu tác tử chỉnh sửa cho đến khi nội dung hợp lý, ngắn gọn và là điều bạn sẽ tự viết. Bạn là tác giả của mọi thứ bạn đăng.
  • Include in the PR description:
    • Một liên kết phối hợp đến vấn đề hoặc cuộc thảo luận mà người duy trì đã xác nhận công việc.
    • Các lệnh kiểm thử bạn đã chạy và kết quả của chúng (dán kết quả liên quan, không chỉ là “các kiểm thử đã vượt qua”).
    • Ghi chú tự đánh giá của bạn (hoặc liên kết đến bình luận PR chứa chúng), như đã mô tả ở trên.

Nếu bạn là tác giả mô hình hoặc là một phần của nhóm chính thức duy trì một mô hình, chúng tôi khuyến khích bạn sử dụng các agent cho việc tích hợp mô hình mới. Hãy làm theo cấu hình được khuyến nghị của kho lưu trữ và sử dụng kỹ năng model-integration. Hãy phối hợp phạm vi với các người duy trì trước khi mở một PR — xem Thêm pipeline, mô hình, trình lập lịch.

Update on GitHub

←Các dự án được xây dựng với Diffusers Hướng dẫn đạo đức của Diffusers→