IssueHunt[重要‼️]: G2 开源社区用户指南 #6703
interstellarmt posted onGitHub
使用软件产品就像开车，难免会遇到抛锚时刻 🚗💨。对于商业产品，我们可以咨询客服寻求帮助。对于公司自己研发的产品，我们可以直接请教专家同事。但对于开源项目，就像突然找不到手机信号，该怎么办？
别慌！开源世界的生存法则是：70%自助排查 + 30%精准提问 = 100%问题解决！（毕竟维护者都是为爱发电的野生程序员🧑💻，不是24小时客服哦~）
🆘 自救指南
问问搜索引擎和大模型（90%的问题早有答案）🔍
逛逛项目的"问题集锦"（Issues 问题区 和 Discussion 讨论区就像开源版知乎）🗂️
找身边用过的小伙伴请教 （你遇到的问题别人可能也遇到过）👥
如果这些都不管用————✨立刻马上向社区求助！✨
🤝 鼓励参与社区共建
这是一个开源项目, 我们也有繁忙的业务要做, 是用自己的业余时间在维护, 为爱发电, 精力有限, 所以有时候 issue 响应速度不是那么及时, 如果你遇到了问题, 或者对 Issues 问题区 和 Discussion 讨论区 列表的问题感兴趣, 可以直接认领并尝试修复 ，帮助 G2 变得更好, 而不是一味的埋怨和催促, 我们不是甲方乙方的关系.
💯 如何提交优质 Issue
请先确保你已经完成了自救指南的全部内容。如果是使用问题，不知道怎么用，请移步 Discussion 讨论区。
一个明确、有意义的标题
明确、有意义的标题，可以帮助作者确定问题具体是什么类型、预估需要多少时间解决、是否现在马上解决等。一个好的标题，也有利于社区知识的沉淀和后期搜索。
- 简洁清晰（表达方式优化）
- ❌："我遇到了一个折线图的问题，提示信息显示不出来了" （冗余描述开发场景，未提炼核心）
- ✅："双轴图自定义提示显示undefined" （明确错误现象和受影响功能模块，删除非必要状语，保留主干问题）
- 关键特征（内容完整性要求）
- ❌："使用仪表盘后网页崩溃" （未指明环境版本和具体错误类型）
- ✅："vue3 引用 g2 5.1.15 报错index.esm.js:617 Uncaught TypeError: Cannot read properties of undefined (reading 'font') " （包含版本、环境、错误类型三重关键信息）
- 避免情绪化的表达
- ❌："一个很简单的饼图 我居然查了一整天api 没搞出来。。。" （情绪化表达，无法解决任何问题）
- ✅："饼图文档相关配置描述错误" （详细列出错误的位置，快速定位，方便修改文档）
遵循良好的模板
目前 G2 已经内置了issue模板，遵循这个模板去描述问题，能够为高效的沟通 💬 省下不少时间。如果未按照模板填写，内容缺失且未及时补充，维护者可能会错过你的问题。
Describe the bug / 问题描述
- 请填写你具体的问题描述，请不要惜字如金，尽可能的多提供一些你能想到的有用信息。
- 如包含代码块，请使用 Markdown 语法，正确的语法、清晰的格式，可以让读者赏心悦目，也就更有心情帮你一起思考解决问题。
- 特定场景下触发的问题，请在描述里写明，例如
高并发场景下/SSR渲染。
Reproduction link / 复现链接
- 请不要粘贴你自己的业务代码，或者
代码在我本地，不方便分享。 - 请提供去除业务意义的最小可复现 Demo，你可以使用 CodeSandbox) 或者 StackBlitz) 重现你的问题，或者在官网的图表示例里编写完后，点击右上角工具栏将代码转成 codesandbox 并将对应的链接附上，方便维护者排查问题。
- 请尽量不要粘贴代码的截图，使用 Markdown 语法是更好的选择。
Steps to Reproduce the Bug or Issue / 重现步骤
- 若问题需特定交互触发，请用有序列表写明操作链路。仅附错误截图而不说明触发路径，可能导致维护者无法定位关键复现条件。
- 示例： a. 先进行slider交互 b. 再进行brushHighlight交互 c. 监听brush:end事件 d. 获得的data里的selection不正确。
Version / 版本
- 获取真实安装版本
npm list <package> - 检查锁文件，确认依赖树
（yarn.lock/package-lock.json）Browser / 浏览器和 OS / 操作系统
你用的 windows 还是 macOS, 版本是多少，用的什么浏览器，版本是多少？花上一点点时间填写，可以节省后续的很多重复问答。
其他
还有一些需要注意的是：
- 提交前搜索：使用搜索栏检查是否已有类似Issue
- 单Issue单问题：避免在一个Issue中混合多个问题
- 及时更新：当问题有进展时补充评论说明
- 礼貌沟通：使用友好语言（如："建议..." 替代 "你们应该..."）
👍 Upvote / 👎 Downvote 机制
当提交问题前，发现同类issue已有讨论但尚未解决时，建议直接在现有issue下参与讨论。 可通过点赞（👍）表达关注并补充有价值的技术细节（如复现环境、日志截图等），这种协作方式既能避免重复提交，又能集中开发者注意力，推动问题解决效率。 下面介绍一下 Github 中的 Upvote 和 Downvote 机制。
在在 GitHub 中，投票是表达态度的重要方式，它能帮助我们：
- 发现最受关注的问题
- 了解社区的真实需求
- 合理分配开发资源
- Upvote (👍) ：表示支持某个问题或建议，帮助提高其优先级。点赞越多，问题的处理优先级通常越高。
- Downvote (👎) ：表示反对某个问题或建议，通常用于标记不相关或低价值的内容。
🩺 Issue 分诊机制
Issue 提交不应是单向的问题提出，而应作为持续追踪的协同工作流程。你需要及时跟进问题状态变更与修复进展，以下将系统说明Issue分诊机制的核心要素与实施规范。
创建 issue
创建成功后，会自动打上waiting for maintainer标签，此时只需要等待维护者回复。
与维护者有效沟通
维护者可能会要求提供更多信息或修改问题描述，此时 issue 会被打上waiting for author标签或者need improvement标签。确保在 7 天内提供所需信息，直到问题被明确标记为 Bug 或 Feature。
关注 Issue 状态
- Bug 类问题 如果被标记为 todos，表示计划修复。如果被标记为 won’t fix，表示该问题不打算修复。
- Feature 类问题 如果被标记为 todos，表示该功能在计划中。如果没有 todos 标签，则需要更多支持（👍）来评估是否加入开发计划。
- 关闭 Issue 当问题被解决并关联到 PR 后，issue 会被关闭，表示已处理。发布新版本后，系统会自动回复，告知该功能或修复已包含在最新版本中。
Issue 标签
| Label | Hex | Description |
|---|---|---|
| waiting for maintainer | #bcf5db | 需要维护者进行问题分诊或介入处理 |
| waiting for author | #fef2c0 | 需要问题提交者提供更多信息 |
| need improvement | #fbca04 | 信息不完整或格式不符合要求 |
| bug 🐛 | #ee0701 | 功能异常或存在缺陷 |
| documentation 📖 | #d4c5f9 | 文档改进或新增内容需求 |
| feature 💡 | #a2eeef | 新功能请求或现有功能增强 |
| question 💬 | #cc317c | 普通咨询类问题（将自动转为讨论帖） |
| duplicate | #eeeeee | 该问题或PR已存在，将在引用原始问题后关闭 |
| good first issue | #7057ff | 适合首次贡献者的任务 |
| help wanted | #008672 | 欢迎所有开发者参与，无论经验水平 |
| resolved | #0E8A16 | 问题已修复并包含在最新发行版中 |
| resolved pending release | #0E8A16 | 问题已修复等待版本发布 |
| stale | #eeeeee | 长期无进展或问题已解决，将自动关闭 |
| wontfix | #eeeeee | 该问题将不予处理，可能自动关闭 |
| notabug | #eeeeee | 经核实不属于程序缺陷（如误报、无法复现等），将自动关闭 |
| --- |
最后
在开源世界的星河里，每颗代码的星光都源自开发者赤诚的热爱。你提交的每个issue不仅是问题追踪单，更是推动我们不断改进的动力。我们始终以敬畏之心对待每份反馈，但正如夜航船需要灯塔指引，完善的复现步骤与清晰的表述将让问题定位事半功倍。 开源社区这个由全球开发者共建的伊甸园，既需要严谨的技术探讨，也渴求温暖的人文关怀。维护者在深夜调试的咖啡，贡献者在周末提交的PR，都值得用一句真挚的"感谢"来点亮。当你受惠于开源项目时，不妨将这份善意传递——帮助解答新手疑问，参与文档翻译，或简单地为优质项目点亮Star，都是对开源精神最美的诠释。 延伸阅读：