Wails 增强提案WEP全流程指南从 Idea 到 Implemented 的官方路线图【免费下载链接】wailsCreate beautiful applications using Go项目地址: https://gitcode.com/gh_mirrors/wa/wailsWails 增强提案Wails Enhancement Proposal简称 WEP是 Wails 项目用来正式记录新能力提案或公共行为变更的规范化机制任何新功能、公共 API 或破坏性变更都必须以 WEP 的形式通过 Pull Request 提交而不是作为功能请求 Issue 提出。本文以仓库中的 WEP 流程文档 为骨架结合 WEP 模板 与已实施的 WEP 0001Customising Window Controls以及v3/pkg/application下的真实实现代码完整讲解提案的编写、提交、评审、决策与实施全过程帮助你理解 Wails 社区如何协作演进并掌握撰写一份合格 WEP 的实操方法。什么是 WEP为什么需要它WEPWails Enhancement Proposal是 Wails 项目中对拟议的 Wails 能力或公共行为变更的正式记录。它有两个鲜明特征以 PR 为载体WEP 以 Pull Request 形式提交而不是功能请求 Issue评审过程即 PR 讨论过程两阶段流程先创建 WEP记录想法、提交评审、社区讨论、完善后实施 WEP开发功能、提交实现 PR、根据反馈迭代直至合并与文档化。这一结构化流程保证了 Wails 增强工作的透明性、社区参与度和推进效率。在正式提交前需要区分不同沟通渠道的用途渠道适用场景GitHub Issues可复现的 Bug、文档问题GitHub Discussions提问、非正式的前置讨论WEP PR正式的增强提案是维护者做出决策的唯一依据需要特别强调的是一次 Discussion 讨论并不等于提案被批准维护者只有在收到 WEP PR 之后才会对增强做出正式决定。我需要一份 WEP 吗并非所有变更都需要提案文档给出了明确的判断原则需要 WEP 的情况新增功能new functionality新增公共 API 或选项改变公共行为破坏性变更breaking changes跨平台工作重大的平台特定工作不需要 WEP 的情况已确认的 Bug 修复仅文档变更无外部可观察行为变化的内部重构走标准 PR 流程即可如果不确定可以在 GitHub Discussions 的 Ideas 分类或官方 Discord 社区先行询问避免在方向重叠上投入过多精力。创建 WEP四步实操流程1. Idea Initiation想法启动试探兴趣可选写作前先在 Discussions 的 Ideas 分类或 Discord 中抛出想法提前发现与既有计划的冲突文档化你的想法在仓库中新建目录v3/wep/proposals/name of proposal目录名即 WEP 名称将位于 v3/wep/WEP_TEMPLATE.md 的模板复制为v3/wep/proposals/name of proposal/proposal.md附加资源图片、图表等一并放入提案目录按模板填充细节不得删除任何模板小节。以仓库中唯一的提案 proposals/0001-titlebar-buttons/proposal.md 为例其目录结构为v3/wep/proposals/0001-titlebar-buttons/内部仅包含一个proposal.md文件——这正是提案 PR 只包含提案文件与附加资源这一规则的体现。2. Submit a WEP提交提案以DRAFT PR提交 WEP标题格式为[WEP] titlePR 中只应包含提案文件及附加资源图片、图表等在 PR 描述中添加提案摘要。3. Community Discussion社区讨论分享你的 WEPPR 是官方讨论场所向 Wails 社区展示提案并争取支持可同步分享到 Discord 的#enhancement-proposals频道收集反馈所有反馈应作为 PR 评论保留使讨论与文档绑定在一起表达支持社区可通过 Reaction 表达兴趣但维护者最终基于技术价值、兼容性、维护成本与项目契合度做决定迭代根据反馈持续修改 WEP确定实现者为避免提案停滞必须有人同意实施该提案可以是提案者本人进入评审提案就绪后将 PR 状态改为Ready for Review。流程要求至少留出 2 周时间供社区反馈与讨论。4. Final Decision最终决策维护者综合社区反馈与提案价值做出最终决定决定以特定格式记录在 PR 评论中**Decision**: Accepted / Rejected **Decided by**: maintainer(s) **Rationale**: A short explanation of the decision.若接受AcceptedWEP 获得下一个编号目录重命名为NNNN-name of proposal状态更新为Accepted加入 WEP IndexPR 被合并若拒绝RejectedPR 关闭WEP 仍记录在 WEP Index 中并链接到决定评论便于该想法将来再次出现时快速追溯若撤回Withdrawn提案未获得必要支持或超过一个月无活动可能以Withdrawn状态关闭。提案实施从 Accepted 到 ImplementedWEP 被接受后进入实施阶段同样分为三步1. 开发功能Develop the Feature遵循标准按 Wails 编码规范实现功能文档化开发过程中同步完善功能文档提交 PR实现完成后提交功能 PR。2. 反馈与迭代Feedback and Iteration收集社区反馈基于反馈持续改进。3. 合并Merging处理 PR 评审意见评审通过后合并更新状态实现 PR 合并时将 WEP 状态更新为Implemented并将实现 PR 链接加入 WEP Index。注意接受的前提是有承诺的实施者。若接受后 3 个月内未启动实施该 WEP 会在 WEP Index 中被标记为 up for grabs任何人均可接手。WEP 模板逐节解析一份合格提案必备的 13 个部分WEP 模板v3/wep/WEP_TEMPLATE.md定义了提案必须覆盖的全部小节从 WEP 0001 的实际内容可以看出每个部分的写法元信息区标题下方WEP Number留空接受时统一分配WEP 0001 中为0001Status初始为DraftWEP 0001 最终为ImplementedAuthor / Created / Discussion / Implementor作者、创建日期0001 为2024-05-20、讨论链接、已承诺实现者Target目标版本0001 标注为Wails v3。正文 13 节小节要求WEP 0001 示例Summary提案的简明摘要提案为 Windows/macOS 提供控制窗口控件外观与功能的 APIMotivation要解决的问题及必要性当前不完全支持定制窗口控件Detailed Design技术细节、实现步骤、对既有功能的影响新的ButtonState枚举、WebviewWindowOptions新字段、Window接口新方法Non-Goals明确不覆盖的范围—Platform Considerations各平台Windows/macOS/Linux/移动端行为、限制与 API 差异Windows 与 Mac 对 Hide 语义的差异、无 Linux 支持Pros/Cons方案优缺点优点补齐 mac/win 定制能力缺点平台行为差异、无 Linux 支持Alternatives Considered考虑过的替代方案替代方案是自绘标题栏但工作量大且观感差Backwards Compatibility向后兼容问题不兼容——移除了旧的 disable button 选项Security and Privacy安全、隐私、权限、数据处理影响无则明说—Test Plan测试策略更新 window 示例用于测试Reference Implementation参考实现或原型链接随提案附带参考实现Maintenance Plan长期维护与支持方式由 Wails 开发者维护支持Conclusion收益总结与最终考量该 API 将赋予开发者对窗口外观更大的控制力模板要求所有小节不得删除这保证了评审者对每个提案都能拿到一致、完整的信息维度尤其是平台差异、兼容性、安全性与维护责任这些容易被忽略的关键决策点。案例深挖WEP 0001 在 v3 源码中的落地WEP 0001Customising Window Controls从提案到实现的全过程是理解 WEP 流程如何转化为真实代码的最佳范本。对照 WEP 0001 提案 与 webview_window_options.go 中的实现1. ButtonState 枚举提案中的设计在源码 webview_window_options.go 中原样落地type ButtonState int const ( ButtonEnabled ButtonState 0 ButtonDisabled ButtonState 1 ButtonHidden ButtonState 2 )值得一提的是实现中还额外演化出了FullscreenButtonState字段webview_window_options.go并配套effectiveZoomButtonState辅助函数由于 macOS 上全屏按钮与最大化按钮共享同一个NSWindowZoomButton取两者中更严格的状态Hidden Disabled Enabled与常量整数排序一致防止运行期两个 setter 互相覆盖见 webview_window_options.go 与 webview_window_darwin.go。2. WebviewWindowOptions 新字段三个按钮状态字段直接加在WebviewWindowOptions上webview_window_options.go// Toolbar button states MinimiseButtonState ButtonState MaximiseButtonState ButtonState CloseButtonState ButtonState3. Window 接口方法运行期动态控制通过Window接口方法暴露webview_window.go 中的实现会同步更新 options 并经由InvokeSync转发到平台实现func (w *WebviewWindow) SetMinimiseButtonState(state ButtonState) Window { w.options.MinimiseButtonState state if w.impl ! nil { InvokeSync(func() { w.impl.setMinimiseButtonState(state) }) } return w } // SetMaximiseButtonState / SetCloseButtonState / SetFullscreenButtonState 结构相同4. 平台差异的真实映射提案中的平台行为表格在源码中得到了精确印证操作Windows 实现webview_window_windows.gomacOS 实现webview_window_darwin.goDisable Min/Max/Close清除WS_MINIMIZEBOX/WS_MAXIMIZEBOX样式Close 经EnableCloseButton/DisableCloseButton禁用经 C 桥接调用 AppKit 设置按钮 enabled 状态Hide Min禁用 MinWindows 无法单独隐藏隐藏 Min 按钮Hide Max禁用 MaxWindows 无法单独隐藏隐藏 Max 按钮Hide Close清除WS_SYSMENU隐藏全部控件隐藏 Close 按钮Linux空操作webview_window_linux.go 中三个 setter 均为空实现与提案无 Linux 支持的结论一致—5. Windows 扩展样式 ExStyle提案第二部分为WebviewWindowOptions新增ExStyle int字段实现中位于WindowsWindow结构体webview_window_options.go。窗口创建时若显式设置了ExStyle则直接覆盖默认计算出的扩展样式webview_window_windows.goif options.Windows.ExStyle ! 0 { exStyle options.Windows.ExStyle }提案中的完整示例可直接运行其依赖的样式常量定义于 v3/pkg/w32/constants.gopackage main import ( github.com/wailsapp/wails/v3/pkg/application github.com/wailsapp/wails/v3/pkg/w32 ) func main() { app : application.New(application.Options{ Name: My Application, }) app.NewWebviewWindowWithOptions(application.WebviewWindowOptions{ Windows: application.WindowsWindow{ ExStyle: w32.WS_EX_TOOLWINDOW | w32.WS_EX_NOREDIRECTIONBITMAP | w32.WS_EX_TOPMOST, }, }) app.Run() }其中各常量含义为WS_EX_TOPMOST0x00000008置顶、WS_EX_TOOLWINDOW0x00000080工具窗口从任务栏隐藏且不抢占键盘焦点、WS_EX_NOREDIRECTIONBITMAP0x00200000禁用重定向位图、WS_EX_APPWINDOW0x00040000强制显示在任务栏。默认构建逻辑中HiddenOnTaskbar会切换WS_EX_TOOLWINDOW与WS_EX_APPWINDOW见 webview_window_windows.go。6. 验证与示例WEP 0001 的 Test Plan更新 window 示例以测试功能已在 v3/examples/window/main.go 中落地创建窗口时通过WebviewWindowOptions设置初始按钮状态例如MinimiseButtonState: application.ButtonDisabledmain.go、CloseButtonState: application.ButtonHiddenmain.go运行期通过SetMinimiseButtonState/SetMaximiseButtonState/SetCloseButtonState动态切换 Enable/Disable/Hide 三种状态main.goWindows 专属的 Custom ExStyle 示例在 windows.go 中以w32.WS_EX_TOOLWINDOW | w32.WS_EX_NOREDIRECTIONBITMAP | w32.WS_EX_TOPMOST组合演示main.go。WEP Index提案的公共台账仓库 WEP Index 以表格形式维护所有提案的流转状态WEPTitleStatusProposalImplementation0001Customising Window ControlsImplementedproposal同提案 PR状态机包括五种Draft讨论中、Accepted已批准待实施、Implemented已发布、Rejected已拒绝、Withdrawn作者关闭或因不活跃关闭。Index 的存在让任何想法无论成败都有据可查被拒绝的提案同样被记录并链接决定避免社区重复提出已被评估过的方向。小结如何有效参与 Wails 增强流程把以上内容浓缩为可直接执行的 checklist先判断新功能/公共 API/破坏性变更才需要 WEPBug 修复与文档走普通 PR再试探在 Discussions/Discord 预沟通避免方向冲突按模板撰写复制 WEP_TEMPLATE.md 到v3/wep/proposals/name/proposal.md13 个小节全部保留、逐一填实以 DRAFT PR 提交标题[WEP] title只含提案与资源至少讨论 2 周迭代打磨并确定实施者再转为Ready for Review等待维护者决策Accepted 后目录重命名为NNNN-name并登记入 WEP IndexRejected 也会留档备查实施并闭环按标准开发 → 提交实现 PR → 合并后将状态更新为Implemented并补全 Index。WEP 0001 从 2024-05-20 的提案到源码中完整的 Windows/macOS 实现与示例正是这套流程结构化、协作式增强 Wails目标的实证。无论是提交你自己的提案还是实现一个标记为 up for grabs 的既有 WEP以上流程都为你提供了清晰可循的路径。【免费下载链接】wailsCreate beautiful applications using Go项目地址: https://gitcode.com/gh_mirrors/wa/wails创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Wails 增强提案（WEP）全流程指南：从 Idea 到 Implemented 的官方路线图
Wails 增强提案WEP全流程指南从 Idea 到 Implemented 的官方路线图【免费下载链接】wailsCreate beautiful applications using Go项目地址: https://gitcode.com/gh_mirrors/wa/wailsWails 增强提案Wails Enhancement Proposal简称 WEP是 Wails 项目用来正式记录新能力提案或公共行为变更的规范化机制任何新功能、公共 API 或破坏性变更都必须以 WEP 的形式通过 Pull Request 提交而不是作为功能请求 Issue 提出。本文以仓库中的 WEP 流程文档 为骨架结合 WEP 模板 与已实施的 WEP 0001Customising Window Controls以及v3/pkg/application下的真实实现代码完整讲解提案的编写、提交、评审、决策与实施全过程帮助你理解 Wails 社区如何协作演进并掌握撰写一份合格 WEP 的实操方法。什么是 WEP为什么需要它WEPWails Enhancement Proposal是 Wails 项目中对拟议的 Wails 能力或公共行为变更的正式记录。它有两个鲜明特征以 PR 为载体WEP 以 Pull Request 形式提交而不是功能请求 Issue评审过程即 PR 讨论过程两阶段流程先创建 WEP记录想法、提交评审、社区讨论、完善后实施 WEP开发功能、提交实现 PR、根据反馈迭代直至合并与文档化。这一结构化流程保证了 Wails 增强工作的透明性、社区参与度和推进效率。在正式提交前需要区分不同沟通渠道的用途渠道适用场景GitHub Issues可复现的 Bug、文档问题GitHub Discussions提问、非正式的前置讨论WEP PR正式的增强提案是维护者做出决策的唯一依据需要特别强调的是一次 Discussion 讨论并不等于提案被批准维护者只有在收到 WEP PR 之后才会对增强做出正式决定。我需要一份 WEP 吗并非所有变更都需要提案文档给出了明确的判断原则需要 WEP 的情况新增功能new functionality新增公共 API 或选项改变公共行为破坏性变更breaking changes跨平台工作重大的平台特定工作不需要 WEP 的情况已确认的 Bug 修复仅文档变更无外部可观察行为变化的内部重构走标准 PR 流程即可如果不确定可以在 GitHub Discussions 的 Ideas 分类或官方 Discord 社区先行询问避免在方向重叠上投入过多精力。创建 WEP四步实操流程1. Idea Initiation想法启动试探兴趣可选写作前先在 Discussions 的 Ideas 分类或 Discord 中抛出想法提前发现与既有计划的冲突文档化你的想法在仓库中新建目录v3/wep/proposals/name of proposal目录名即 WEP 名称将位于 v3/wep/WEP_TEMPLATE.md 的模板复制为v3/wep/proposals/name of proposal/proposal.md附加资源图片、图表等一并放入提案目录按模板填充细节不得删除任何模板小节。以仓库中唯一的提案 proposals/0001-titlebar-buttons/proposal.md 为例其目录结构为v3/wep/proposals/0001-titlebar-buttons/内部仅包含一个proposal.md文件——这正是提案 PR 只包含提案文件与附加资源这一规则的体现。2. Submit a WEP提交提案以DRAFT PR提交 WEP标题格式为[WEP] titlePR 中只应包含提案文件及附加资源图片、图表等在 PR 描述中添加提案摘要。3. Community Discussion社区讨论分享你的 WEPPR 是官方讨论场所向 Wails 社区展示提案并争取支持可同步分享到 Discord 的#enhancement-proposals频道收集反馈所有反馈应作为 PR 评论保留使讨论与文档绑定在一起表达支持社区可通过 Reaction 表达兴趣但维护者最终基于技术价值、兼容性、维护成本与项目契合度做决定迭代根据反馈持续修改 WEP确定实现者为避免提案停滞必须有人同意实施该提案可以是提案者本人进入评审提案就绪后将 PR 状态改为Ready for Review。流程要求至少留出 2 周时间供社区反馈与讨论。4. Final Decision最终决策维护者综合社区反馈与提案价值做出最终决定决定以特定格式记录在 PR 评论中**Decision**: Accepted / Rejected **Decided by**: maintainer(s) **Rationale**: A short explanation of the decision.若接受AcceptedWEP 获得下一个编号目录重命名为NNNN-name of proposal状态更新为Accepted加入 WEP IndexPR 被合并若拒绝RejectedPR 关闭WEP 仍记录在 WEP Index 中并链接到决定评论便于该想法将来再次出现时快速追溯若撤回Withdrawn提案未获得必要支持或超过一个月无活动可能以Withdrawn状态关闭。提案实施从 Accepted 到 ImplementedWEP 被接受后进入实施阶段同样分为三步1. 开发功能Develop the Feature遵循标准按 Wails 编码规范实现功能文档化开发过程中同步完善功能文档提交 PR实现完成后提交功能 PR。2. 反馈与迭代Feedback and Iteration收集社区反馈基于反馈持续改进。3. 合并Merging处理 PR 评审意见评审通过后合并更新状态实现 PR 合并时将 WEP 状态更新为Implemented并将实现 PR 链接加入 WEP Index。注意接受的前提是有承诺的实施者。若接受后 3 个月内未启动实施该 WEP 会在 WEP Index 中被标记为 up for grabs任何人均可接手。WEP 模板逐节解析一份合格提案必备的 13 个部分WEP 模板v3/wep/WEP_TEMPLATE.md定义了提案必须覆盖的全部小节从 WEP 0001 的实际内容可以看出每个部分的写法元信息区标题下方WEP Number留空接受时统一分配WEP 0001 中为0001Status初始为DraftWEP 0001 最终为ImplementedAuthor / Created / Discussion / Implementor作者、创建日期0001 为2024-05-20、讨论链接、已承诺实现者Target目标版本0001 标注为Wails v3。正文 13 节小节要求WEP 0001 示例Summary提案的简明摘要提案为 Windows/macOS 提供控制窗口控件外观与功能的 APIMotivation要解决的问题及必要性当前不完全支持定制窗口控件Detailed Design技术细节、实现步骤、对既有功能的影响新的ButtonState枚举、WebviewWindowOptions新字段、Window接口新方法Non-Goals明确不覆盖的范围—Platform Considerations各平台Windows/macOS/Linux/移动端行为、限制与 API 差异Windows 与 Mac 对 Hide 语义的差异、无 Linux 支持Pros/Cons方案优缺点优点补齐 mac/win 定制能力缺点平台行为差异、无 Linux 支持Alternatives Considered考虑过的替代方案替代方案是自绘标题栏但工作量大且观感差Backwards Compatibility向后兼容问题不兼容——移除了旧的 disable button 选项Security and Privacy安全、隐私、权限、数据处理影响无则明说—Test Plan测试策略更新 window 示例用于测试Reference Implementation参考实现或原型链接随提案附带参考实现Maintenance Plan长期维护与支持方式由 Wails 开发者维护支持Conclusion收益总结与最终考量该 API 将赋予开发者对窗口外观更大的控制力模板要求所有小节不得删除这保证了评审者对每个提案都能拿到一致、完整的信息维度尤其是平台差异、兼容性、安全性与维护责任这些容易被忽略的关键决策点。案例深挖WEP 0001 在 v3 源码中的落地WEP 0001Customising Window Controls从提案到实现的全过程是理解 WEP 流程如何转化为真实代码的最佳范本。对照 WEP 0001 提案 与 webview_window_options.go 中的实现1. ButtonState 枚举提案中的设计在源码 webview_window_options.go 中原样落地type ButtonState int const ( ButtonEnabled ButtonState 0 ButtonDisabled ButtonState 1 ButtonHidden ButtonState 2 )值得一提的是实现中还额外演化出了FullscreenButtonState字段webview_window_options.go并配套effectiveZoomButtonState辅助函数由于 macOS 上全屏按钮与最大化按钮共享同一个NSWindowZoomButton取两者中更严格的状态Hidden Disabled Enabled与常量整数排序一致防止运行期两个 setter 互相覆盖见 webview_window_options.go 与 webview_window_darwin.go。2. WebviewWindowOptions 新字段三个按钮状态字段直接加在WebviewWindowOptions上webview_window_options.go// Toolbar button states MinimiseButtonState ButtonState MaximiseButtonState ButtonState CloseButtonState ButtonState3. Window 接口方法运行期动态控制通过Window接口方法暴露webview_window.go 中的实现会同步更新 options 并经由InvokeSync转发到平台实现func (w *WebviewWindow) SetMinimiseButtonState(state ButtonState) Window { w.options.MinimiseButtonState state if w.impl ! nil { InvokeSync(func() { w.impl.setMinimiseButtonState(state) }) } return w } // SetMaximiseButtonState / SetCloseButtonState / SetFullscreenButtonState 结构相同4. 平台差异的真实映射提案中的平台行为表格在源码中得到了精确印证操作Windows 实现webview_window_windows.gomacOS 实现webview_window_darwin.goDisable Min/Max/Close清除WS_MINIMIZEBOX/WS_MAXIMIZEBOX样式Close 经EnableCloseButton/DisableCloseButton禁用经 C 桥接调用 AppKit 设置按钮 enabled 状态Hide Min禁用 MinWindows 无法单独隐藏隐藏 Min 按钮Hide Max禁用 MaxWindows 无法单独隐藏隐藏 Max 按钮Hide Close清除WS_SYSMENU隐藏全部控件隐藏 Close 按钮Linux空操作webview_window_linux.go 中三个 setter 均为空实现与提案无 Linux 支持的结论一致—5. Windows 扩展样式 ExStyle提案第二部分为WebviewWindowOptions新增ExStyle int字段实现中位于WindowsWindow结构体webview_window_options.go。窗口创建时若显式设置了ExStyle则直接覆盖默认计算出的扩展样式webview_window_windows.goif options.Windows.ExStyle ! 0 { exStyle options.Windows.ExStyle }提案中的完整示例可直接运行其依赖的样式常量定义于 v3/pkg/w32/constants.gopackage main import ( github.com/wailsapp/wails/v3/pkg/application github.com/wailsapp/wails/v3/pkg/w32 ) func main() { app : application.New(application.Options{ Name: My Application, }) app.NewWebviewWindowWithOptions(application.WebviewWindowOptions{ Windows: application.WindowsWindow{ ExStyle: w32.WS_EX_TOOLWINDOW | w32.WS_EX_NOREDIRECTIONBITMAP | w32.WS_EX_TOPMOST, }, }) app.Run() }其中各常量含义为WS_EX_TOPMOST0x00000008置顶、WS_EX_TOOLWINDOW0x00000080工具窗口从任务栏隐藏且不抢占键盘焦点、WS_EX_NOREDIRECTIONBITMAP0x00200000禁用重定向位图、WS_EX_APPWINDOW0x00040000强制显示在任务栏。默认构建逻辑中HiddenOnTaskbar会切换WS_EX_TOOLWINDOW与WS_EX_APPWINDOW见 webview_window_windows.go。6. 验证与示例WEP 0001 的 Test Plan更新 window 示例以测试功能已在 v3/examples/window/main.go 中落地创建窗口时通过WebviewWindowOptions设置初始按钮状态例如MinimiseButtonState: application.ButtonDisabledmain.go、CloseButtonState: application.ButtonHiddenmain.go运行期通过SetMinimiseButtonState/SetMaximiseButtonState/SetCloseButtonState动态切换 Enable/Disable/Hide 三种状态main.goWindows 专属的 Custom ExStyle 示例在 windows.go 中以w32.WS_EX_TOOLWINDOW | w32.WS_EX_NOREDIRECTIONBITMAP | w32.WS_EX_TOPMOST组合演示main.go。WEP Index提案的公共台账仓库 WEP Index 以表格形式维护所有提案的流转状态WEPTitleStatusProposalImplementation0001Customising Window ControlsImplementedproposal同提案 PR状态机包括五种Draft讨论中、Accepted已批准待实施、Implemented已发布、Rejected已拒绝、Withdrawn作者关闭或因不活跃关闭。Index 的存在让任何想法无论成败都有据可查被拒绝的提案同样被记录并链接决定避免社区重复提出已被评估过的方向。小结如何有效参与 Wails 增强流程把以上内容浓缩为可直接执行的 checklist先判断新功能/公共 API/破坏性变更才需要 WEPBug 修复与文档走普通 PR再试探在 Discussions/Discord 预沟通避免方向冲突按模板撰写复制 WEP_TEMPLATE.md 到v3/wep/proposals/name/proposal.md13 个小节全部保留、逐一填实以 DRAFT PR 提交标题[WEP] title只含提案与资源至少讨论 2 周迭代打磨并确定实施者再转为Ready for Review等待维护者决策Accepted 后目录重命名为NNNN-name并登记入 WEP IndexRejected 也会留档备查实施并闭环按标准开发 → 提交实现 PR → 合并后将状态更新为Implemented并补全 Index。WEP 0001 从 2024-05-20 的提案到源码中完整的 Windows/macOS 实现与示例正是这套流程结构化、协作式增强 Wails目标的实证。无论是提交你自己的提案还是实现一个标记为 up for grabs 的既有 WEP以上流程都为你提供了清晰可循的路径。【免费下载链接】wailsCreate beautiful applications using Go项目地址: https://gitcode.com/gh_mirrors/wa/wails创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考