向VS Code贡献需先查重、用模板报issue，再fork仓库、按规范开发测试并提PR；必读CONTRIBUTING.md、签署CLA，CI通过且沟通及时方能合入。
向 VS Code 官方仓库贡献代码或报告问题，核心是遵循其开源协作规范——主要用 GitHub 管理，流程清晰但需注意细节。
报告问题：先查重、再写清楚
绝大多数用户贡献始于提交 issue。关键不是“快”，而是“准”：
- 先搜 GitHub Issues 页面，确认问题没被提过（用关键词 + “is:issue is:open” 过滤）
- 使用官方提供的 Issue 模板（Bug Report / Feature Request），填全必填项：VS Code 版本、操作系统、复现步骤、预期 vs 实际行为
- 附上截图、GIF 或日志（如开发者工具控制台错误、`code --verbose` 输出）能极大提升响应效率
- 避免模糊描述，比如“插件不工作” → 改成“在启用 Prettier 插件 v9.12.0 后，保存 .js 文件时无格式化反应，控制台报错 ‘TypeError: Cannot read property 'format' of undefined’”
贡献代码：从 fork 到 PR，走标准流程
VS Code 主仓库（https://github.com/microsoft/vscode）只接受通过 Pull Request 的代码变更，不直推：
- 先 Fork 仓库到自己账号，克隆本地，配置 upstream 追踪主仓库更新
- 基于 main 分支 新建特性/修复分支（如
fix-webview-focus-loss），不要用 master -
编码前看根目录的
CONTRIBUTING.md和development/下文档，了解构建方式（Electron + TypeScript）、测试要求（单元测试 + E2E）、代码风格（Prettier + TSLint） - 运行
npm run watch启动开发版验证修改，跑通相关测试（npm test或针对性运行 test/unit） - 提交时写清晰的 commit message（首行 ≤ 50 字，说明改动意图；body 补充背景和影响），关联 issue（如
Fixes #12345） - Push 到自己 fork 后，在 GitHub 上发起 PR，选择对应模板，填写变更说明、测试方法、影响范围
参与前必读：规则、范围与沟通习惯
VS Code 团队对贡献有明确边界和偏好，提前了解可少走弯路：
- 核心功能变更需先在对应 issue 下讨论达成共识，不鼓励直接提大 PR
- 文档、翻译、小 bug 修复、测试补充等类型贡献更易被快速合入
- 所有 PR 必须通过 CI（包括 Windows/macOS/Linux 三端构建、测试、代码扫描），CI 失败需主动修复
- 团队常用 GitHub 评论 + Discord（#contributing 频道）沟通，保持礼貌、简洁、响应及时；避免催促，耐心等待 Review（通常 1–3 个工作日）
- 签署 Contributor License Agreement (CLA) 是合并前提，首次 PR 会自动引导完成
基本上就这些。不复杂但容易忽略细节，尤其查重、模板填写和本地验证这三步，踩中任一都可能让 issue 被关闭或 PR 被搁置。
