[proposal] Roadmap after v0.4

seeflood commented 2 years ago

Layotto 最近发布了 v0.4-rc 版本，开源至今已经有很多生产用户了。项目刚发布时的 Roadmap 倾向于通过头脑风暴来决策"要做什么功能"，现在既然我们已经有了生产用户，是时候调整一下 Roadmap 啦。

本文作为提案，讨论 v0.4 发布之后，社区:

如何决策哪些需求做、哪些不做
如何决策 "未来的 Roadmap"
如何判断 "要做的需求中，哪个优先级更高"
目前已知的需求和 Roadmap

需求从哪来

用户需求

做"用户需求"，或者做"能让我们获得更多用户"的需求。

比如，在调研选型的用户非常关心 A 功能，那么 A 功能就属于"能让我们获得更多用户"的需求。

Moonshot

指：目前没有明确的用户需求，但是有很好的技术前景、contributor 有兴趣去做的功能。比如靠 eBPF 优化性能，比如继续完善"通过 WASM 做 Serverless" 的功能，比如 Transaction Mesh

如何决策"这个需求做不做"、"未来的 Roadmap 是什么"

流程:

step 1. 如果有新的需求、新的提案，建议发 issue，比如 https://github.com/mosn/layotto/issues/392 比如 https://github.com/mosn/layotto/issues/448

Q: 如何决策"这个需求做不做"?

step 2. 社区 review 后，如果没有反对意见，就代表这个需求"可以做"，issue 将被挪进 Roadmap 的 To do list, 放入需求池

Q: 这个需求谁来做?

step 3. 谁认领谁来做。如果社区有人愿意"认领"该需求、愿意近期做，issue 将从 To do list 挪进 In design阶段。

建议认领需求的同学写个系统设计 proposal (当然，简单的需求可以不用写文档)，供其他人 review 方案。

step 4. 如果大家 review 后觉得方案没问题，这个 issue 将被挪进 In development 阶段

Q: 简单的需求还需要走这个流程么？

A: 不需要。简单的需求，记个 issue 后，提 PR 修复即可。减少维护成本。

如何判断"要做的需求中，哪个优先级更高"

回复越多、点 👍 越多的 issue ，优先级越高。

逻辑是：某个需求的优先级高不高，取决于社区的声音

目前已知的用户需求（欢迎认领）

跨云部署：提供一个"样板间"，将某个系统同时部署到阿里云和 AWS 上。见 https://github.com/mosn/layotto/issues/471

一方面，有生产用户提出了跨云部署的需求；另一方面，有了样板间后，我们能更好的做 marketing, 帮助我们得到更多用户。

这个需求其实很大，比如需要和kubernetes 做更好的集成等，比如完善目前的API，比如 #455

【作为开源之夏课题】invokeService API 兼容 istio 1.10. 见 https://github.com/mosn/layotto/issues/311

main 分支最新代码升级了 MOSN 版本，现在已经支持 istio 1.10 了（RPC 流量被 MOSN 拦截,能享受 istio 的流量治理功能, 其他 API 走 Layotto)

但是如果用户希望 RPC 走 Layotto 的 invokeService API、而不是被 MOSN 拦截，那 Layotto 需要做下开发、适配，参考 https://mosn.io/layotto/#/zh/start/istio/start

secret API. https://github.com/mosn/layotto/issues/472 有生产用户需求
更强大的CI、更多测试

https://github.com/mosn/layotto/issues/532

性能压测报告

这个是调研用户比较关心的问题

sidecar 的 invokeService API 负责做 rpc 协议转换。参考 dubbo-go-pixiu

这个生产用户已经用上了，不过是魔改定制方案、没开源。感觉可以在开源做个通用方案

支持http 协议

同上

需要一个机器人、自动把 github issue 和 pr 的消息推送到开发者群

方便拉人 review

需要个机器人，把 PR 里的图片自动上传到图床/服务器，避免仓库里图太多、仓库越来越大、git clone 越来越慢

目前没有用户需求、但是值得做的事情（欢迎认领)

Transaction Mesh
通过 eBPF 优化性能
完善"通过 WASM 做 Serverless"
通过 WASM 实现组件。见 #476
proxyless runtime Layotto 作为 go sdk，而不是 sidecar。之前提过一个 pr 但是关掉了
layotto-on-pixiu 需要和pixiu 聊，在等答复
通用的超时、重试、熔断功能

seeflood commented 2 years ago

@ZLBer @Xunzhuo @wenxuwan @zhenjunMa 可以一起看下哪些适合作为开源之夏的课题，

我目前想到的有：

invokeService API 适配 istio 1.10 @zhenjunMa
一个或多个 kubernetes 相关的 @Xunzhuo
secret API 功能完善 @seeflood ~~- wasm相关的 ~~ 需要再想两个

ZLBer commented 2 years ago

@seeflood 这个有点久了https://github.com/mosn/layotto/issues/189 提个建议，参加开源之夏的同学大多都是开源经验不多，更可能对layotto\istio\k8s这些不熟悉，可能导致题目没人选的结果。组件类的可能更友好，不用学习太多前置知识。还是建议添加一些组件类的任务。

seeflood commented 2 years ago

@ZLBer 恩那我先把 #189 关了，kubernetes 相关的都在 xunzhuo的那个issue下讨论感觉有道理，太高大上的可能离学生比较远，我们可以翻翻还有合适的组件类任务么。感觉拿ceph 做file api组件是一个?

LXPWing commented 2 years ago

其实可以上1~2个有关k8s的议题到开源之夏，我在gsoc中国讨论群发现玩istio\k8s的学生还是挺多的。

seeflood commented 2 years ago

现在的学生好厉害…… 那就每种类型/难度的任务都有，提高一下覆盖面? 比如：组件相关的任务 x 个 k8s 的1~2 个 istio 的 1 个

LXPWing commented 2 years ago

我觉得可以

ZLBer commented 2 years ago

@LXPWing 老哥拉我进gsoc的讨论群玩耍下(^o^)/

Xunzhuo commented 2 years ago

那就每种类型/难度的任务都有，提高一下覆盖面? 比如：

组件相关的任务 x 个

k8s 的1~2 个

istio 的 1 个

是的，可以保留 kubernetes 和 istio 的项目，根据具体内容调整项目难度就好。

LXPWing commented 2 years ago

@ZLBer q群：621656169 欢迎来水群👏

seeflood commented 2 years ago

感觉今年一个很大的失误是没有参加 gsoc 😭 我也进群看看现在的学生都在玩啥

seeflood commented 2 years ago

补充了几个:

需要个机器人，把 PR 里的图片自动上传到图床/服务器，避免仓库里图太多、仓库越来越大、git clone 越来越慢
layotto-on-pixiu 需要和pixiu 聊，在等答复
通用的超时、重试、熔断功能

seeflood commented 2 years ago

关于开源之夏，更新：今年主办方限制课题数目，sofa社区限制4个任务，mosn 社区2个任务所以 layotto 比较尴尬，可能只能发1个或者2个课题

可能的方案： SOFAStack 社区课题：做个 SOFA-boot layotto sdk MOSN 社区课题: layotto 只能发1个，要讨论下是组件/k8s/istio

ZLBer commented 2 years ago

今年这么多限制啊，看来参加的社区挺多啊，卷起来了嗷。把问题都抛出来让参赛者自选吧哈哈。

seeflood commented 2 years ago

今年这么多限制啊，看来参加的社区挺多啊，卷起来了嗷。把问题都抛出来让参赛者自选吧哈哈。

今年的规则有点 emmmmmm... 比如限制社区只能发两个课题，社区就真的只能抛出来2个问题，不能抛出来5个问题、等参赛者选2个

还有个规则是：社区每个课题只能审核通过1个学生，但是1个学生能投3个社区、最后选个喜欢的。

还有一些筛选逻辑比较复杂，概括一下就是：社区很可能花精力发任务、做宣传、沟通半天，最后没人领

所以刚才开会很多人想说服主办方改规则，但都被拒绝了。

咱们就尽力而为吧

Xunzhuo commented 2 years ago

今年这么多限制啊，看来参加的社区挺多啊，卷起来了嗷。把问题都抛出来让参赛者自选吧哈哈。

今年的规则有点 emmmmmm...

比如限制社区只能发两个课题，社区就真的只能抛出来2个问题，不能抛出来5个问题、等参赛者选2个

还有个规则是：社区每个课题只能审核通过1个学生，但是1个学生能投3个社区、最后选个喜欢的。

还有一些筛选逻辑比较复杂，概括一下就是：社区很可能花精力发任务、做宣传、沟通半天，最后没人领

所以刚才开会很多人想说服主办方改规则，但都被拒绝了。

咱们就尽力而为吧

+1 尽力而为吧，可能千辛万苦找来的同学（或者没有）最后鸽了/中途放弃了，对于社区来说参加开源之夏其实更多感觉是培养对社区能够长久贡献的人员，提高开源影响力，但是限制这么多的情况下，一个项目就一两个同学，大家花这么多精力搞这个，还不如咱们自己多花点精力在项目本身来的实在… 本来开源之夏就是对学生和社区双赢的一个活动，现在这样搞的完全变味了，太卷了…

seeflood commented 2 years ago

对我听完之后也是这感觉，还不如多花点精力在项目本身来的实在 😢

github-actions[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue or help wanted) or other activity occurs. Thank you for your contributions.

github-actions[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue or help wanted) or other activity occurs. Thank you for your contributions.

mosn / layotto