Quy trình đóng góp (Issue, PR, API)

Quy trình đóng góp

← Về MOC · Nguồn: README, CONTRIBUTING.md, wiki How to Contribute, Extension API Process

1. Các cách đóng góp (không nhất thiết viết code)

• Báo lỗi (bug) và đề xuất tính năng (feature request) trên GitHub Issues; giúp xác minh bản sửa.
• Review Pull Request (PR – yêu cầu hợp nhất code).
• Sửa tài liệu ở repo microsoft/vscode-docs.
• Góp ý bản dịch ở repo microsoft/vscode-loc.
• Viết code sửa lỗi/tính năng – xem các mục dưới.

2. Chọn issue

Nhãn (label)	Ý nghĩa
good first issue	Phù hợp người mới tiếp xúc code
help wanted	Đội VS Code hoan nghênh PR từ cộng đồng
bug	Lỗi đã xác nhận – cơ hội PR được nhận cao

• Thay đổi lớn hoặc issue đã gán vào milestone tháng → trao đổi với người được giao issue trước.
• Bình luận trên issue rằng bạn đang làm để tránh trùng.
• Thảo luận bằng tiếng Anh, đúng chủ đề, lịch sự.

Không phải issue nào cũng được nhận PR

Wiki nêu 3 lý do PR có thể bị từ chối:

• Hiệu năng: VS Code phải “nhẹ” (lightweight) cả thực tế lẫn cảm nhận.
• Trải nghiệm người dùng (UX): giao diện không được rối; thay đổi UI phải qua chủ issue/đội UX.
• Kiến trúc: thay đổi ảnh hưởng kiến trúc, đặc biệt API extension mới, phải được chủ tính năng đồng ý.

3. Quy trình làm PR

flowchart LR
  A[Fork repo] --> B[Tạo branch trên fork]
  B --> C[Sửa code + test]
  C --> D[eslint / test / hygiene]
  D --> E[Mở PR, liên kết issue]
  E --> F[Ký CLA lần đầu]
  F --> G[Review & sửa]
  G --> H[Merge]

Quy định (wiki How to Contribute – mục Pull Requests):

1. Ký CLA (Contributor License Agreement – thỏa thuận cấp phép cho người đóng góp) – tự động, chỉ một lần.
2. Một PR cho một issue, liên kết issue trong PR. Không gộp nhiều thay đổi trừ khi cùng nguyên nhân gốc.
3. Tuân thủ Coding Guidelines – quy ước viết code, thay đổi càng nhỏ càng tốt.
4. Không sửa định dạng thuần túy ở đoạn code không liên quan.
5. PR nên kèm test khi có thể (Testing – kiểm thử).
6. Kể cả có quyền push vào repo chính, vẫn nên làm trên fork cá nhân.

Mẫu PR (.github/pull_request_template.md) nhắc: đọc hướng dẫn PR, liên kết issue, cập nhật theo nhánh main, mô tả thay đổi và cách kiểm tra.

Quy định commit (.github/instructions/committing.instructions.md): tôn trọng cấu hình ký commit (commit signing); không dùng --no-verify để bỏ qua hook kiểm tra trước commit.

Lưu ý về Electron API

PR phụ thuộc Electron API mà VS Code chưa dùng có rủi ro bị từ chối (API ít phổ biến dễ hỏng khi nâng cấp Electron). Quy tắc:

• Ưu tiên chuẩn web thay vì Electron API (để tính năng chạy được cả trên web).
• Nếu bắt buộc dùng Electron API: cần có unit test ở repo electron/electron để bảo vệ.

Sửa lỗi chính tả

Chào đón PR sửa chính tả trong chuỗi được dịch (trong nls.localize(...)), nhưng không nên trải rộng nhiều feature area (khu vực tính năng). PR chỉ sửa chính tả trong code (không phải chuỗi hiển thị) không được khuyến khích.

4. Quy trình đề xuất Extension API mới

Theo wiki Extension API Process, một API đi qua các giai đoạn:

Giai đoạn	Nội dung	Nhãn issue
Ý tưởng	Tự hỏi: API có khớp với API hiện có? Giải quyết bài toán chung hay chỉ riêng mình? Tái dùng khái niệm cũ (provider, command) hay thêm khái niệm mới?	—
Đề xuất	Mở issue; nếu sửa API cũ thì bắt buộc tương thích ngược; không vi phạm Extension API guidelines	api, api-proposal
Hiện thực / xin phản hồi	API được thêm vào src/vscode-dts/vscode.proposed.<tên>.d.ts; tác giả extension dùng thử trên Insiders	api-feedback
Hoàn thiện (finalization)	Cần ví dụ sử dụng thực tế, được review; chuyển vào vscode.d.ts	—

Liên quan kỹ thuật: Extension Host & RPC.

5. Packaging (đóng gói)

Các tác vụ gulp vscode-[platform] và vscode-[platform]-min (bản rút gọn). Nên chạy qua npm để tránh thiếu bộ nhớ:

npm run gulp vscode-win32-x64-min

Liên kết

• Chủ đề mới đang phát triển mạnh trong repo: Agents Window & AI trong repo