Snopshot提案投票
2023年2月3日（提案）至今
PM已由 @daodao 转移为 @brucexu.eth
steadyforce group @0xhardman 暂时接手widget开发，并联系相关后端+合约开发，进入收尾阶段（正在协调在排行榜功能的开发）
目前项目已进行3个多月，项目成员整体比较疲惫，希望能成功结项。
官网 仓库
仓库
仓库
在Donate3项目组与专家小组进行项目验收时发现项目组成员对需求二有错误理解，
给项目组的哪些成员补发
在LXDAO新的机制下是否能补发一定数量的U？
项目组成员应该以什么样的标准补发多少报酬？
嗯嗯，其实这里面的主要问题是：由于理解或者实施导致的额外的项目投入应该由谁来承担？如何量化和计算？
对于这个问题，我个人倾向于项目组承担大部分的额外成本。通常问题发生的原因有两个：
项目组成员的理解和实施出现偏差，由于沟通、经验和能力层面的不足导致。面对这种问题，我们的优化方案是技术专家小组来做方案 review 并且跟进提供一些技术反馈和建议。这种原因导致的成本增加应该由项目组主要承担，严重时应该更换部分项目组成员并且取消激励发放。
初始需求评审和预算设计不准。这种情况可以申请回溯重新查看当时的预算，如果确实评估少了，可以发布补充提案增发。但是这个衡量标准建立在记录贡献值之上的，例如最新的项目 EIPs Fun 和 MyFirstLayer2 项目采用的贡献记录。以此作为回溯的依据。
此外还暴露了一个问题，项目严重超出了预定工期，原定 PM 不再活跃和积极跟进，只能更换新的 PM 进行推进。对于这个问题：
应该要有所惩罚，比如减少原定的利益分成。需要由专家小组定期跟进，每周进行进展评估和风险暴露，评估是否要及时更换项目组成员。
纯积分启动的项目，没有稳定币，缺少一定的 commitment 和吸引力。这个已经在新的组织架构设计中得到解决。在未来，应该不会启动没有 grants 的项目。
目前我的想法：
原定提案的 90% 积分进行结算，按照过去贡献分配给之前的团队成员，进行结算。
从现在开始，重新 review 和梳理应用现状和上线前剩余需求，并进行重新预估时间和开发成本，并且提交一个增发预算，由原来 10% 的积分 + 新增积分 + < 1500U 的稳定币组成。由 SteadyForce 成员接手项目进行 1 - 2 周的突击开发和上线收尾。
Marcus
May 25, 2023, 10:16am
3
Donate3 When applying for the budget, you need to add these information
1 Like
由于主观原因，历史工作量超出了估算而导致的多余工作，应该由项目组自负盈亏（惩罚或减少）。
当前项目状况，比较同意增加一些预算完成该项目剩余的工作。
项目只差一点就完了，我觉得项目组成员还是有动力收尾的。
在本周末（28号）完成收尾工作
预约专家小组+PM的下周某时间验收
由于我们没有pow记录所以我计划要求项目组成员自主申报多付出的时间作为参考。
1 Like
