这是一个创建于 363 天前的主题，其中的信息可能已经有所发展或是发生改变。
大学毕业工作快三年了，发现自己从来没有参加过开源项目，一直都是写公司的项目；之前也写过一些工具，等写完了在 github 上搜一搜，发现人家已经有更好更全面的实现，成就感一下大打折扣。
也想着参与一些项目的 issues 修复或者开发些 feature ，但我主要领域是 Golang 和 k8s 这块，看的项目主要是 k8s 这种非常庞大的项目，人家修复的效率比我高多了。我也考虑过上 github explore 上找找项目，但是在 explore 上找一个陌生项目，从读代码到解决 bug 效率也比较低，不知道有什么更好的，更易于切入的方式来参与开源项目中
也想着参与一些项目的 issues 修复或者开发些 feature ，但我主要领域是 Golang 和 k8s 这块，看的项目主要是 k8s 这种非常庞大的项目，人家修复的效率比我高多了。我也考虑过上 github explore 上找找项目，但是在 explore 上找一个陌生项目，从读代码到解决 bug 效率也比较低，不知道有什么更好的，更易于切入的方式来参与开源项目中
 |
1
fen 363 天前  1
欢迎来参与 [Apache Answer]( https://github.com/apache/incubator-answer) 的项目，用 golang 写的。我们近期正在完善贡献指南相关文档，方便开发者知道如何参与。
我们会把适合练手的 issue 贴上 [good first issue] 标签，作为参与的第一步。 |
 |
2
AoEiuV020JP 363 天前
不指望靠这个赚钱的话很好办，除了修复别人提的 issue ，如果项目是自己在用的，那总有一些自己的想法吧，或新功能或是改进，自己实现了提个 pr ，不 merge 就自己 fork 玩，
|
 |
3
frankgo007 363 天前
K8s 相关（资源利用优化），项目刚起步，欢迎来： https://github.com/kubefin/kubefin
|
 |
4
InDom 363 天前 7
不要为了参与开源项目而参与。
真的用的，才会真的参与。 |
 |
5
NCZkevin 363 天前
当用到某个开源库，感受到痛点想改进或者遇到 bug 想修复，再去做就会顺畅很多。
如果为了参加而参加目标就会很不明确，当然也可以自己主动去做一个项目多用用开源项目，仔细找找，比如文档、代码冗余、结构优化这些在小项目里应该还是很容易找到并参与的。 |
 |
6
DylanLiuH2O 363 天前 via Android
很难，你不是项目核心成员就没法参与核心需求的设计实现，最多就是一些修修补补的工作，要是你一厢情愿提交一些你觉得比较重要的需求实现，很容易就被驳回了，最后也是徒劳。我目前工作就是基于一个开源的项目做扩展，先是有了组里给的真实需求，然后再去设计实现，感觉这样才真的能参与进去。
|
 |
7
atVoid 363 天前
|
|
8
fen 363 天前
@atVoid 主要沟通渠道为：
- issues https://github.com/apache/incubator-answer/issues - meta https://meta.answer.dev/ - 邮件组 https://lists.apache.org/[email protected] |
 |
9
oebfbe 363 天前 1
|
 |
10
gps949 363 天前
你可以考虑自己创建一个开源项目呀。。。
比如我这边在做 Tailscale 的“自主化”(doge) 版本——蜃境 ： https://github.com/MirageNetwork 可以了解一下。不过这个虽然语言是 Go 为主，但跟 K8S 暂时没啥关系。 我同事那边在研究基于 Tailscale 组网研制 K8S CNI 。你可以搞个这样的开源项目。 |
 |
11
enchilada2020 363 天前 via Android
@DylanLiuH2O 这才是最理想的 可惜大部分人都很少有机会能接触到这样的工作
|
 |
12
cjpjxjx 363 天前 via iPhone
非程序员，给 OpenWrt 贡献了几句翻译和一个小 bug 修复
|
 |
13
chenall 363 天前 via Android
很多开源项目贡献要求要全英文。
像我这种英文不好就很为难，只好自己 fork 一个 给自己贡献了😂 |
 |
14
DianQK 363 天前 via Android
听起来修 k8s 更合适，每个人都要从低效的修复开始成长。在提交 PR 的过程中，应该有很多人愿意帮助你把 PR 完成。（别去抢高优的 Bug 就行）
|
 |
15
kdwnil 363 天前 via Android
参与开源项目不一定要干出惊天动地的 pr ，从简单的做起比如修文档的 typo 也是个不错的开始，或者就是自己用的时候可能有些小 bug 没人提 issue/pr 就可以自己去试着修修。
如果是自己从 0 开新项目就做好前几年都无人问津的准备吧。 不过不管哪一种方式都要贴近自己工作/私活遇到的实际问题/需求，为参与而参与体验会很差的 |
 |
16
monkeyWie 363 天前 via Android
先用，用着发现有问题或者可以改善再去看相关代码和提 pr
|
 |
17
jjshare123 363 天前
@fen 支持开通不同的论坛吗？支持创建多个 Q&A communities 吗？
|
 |
19
Jat001 363 天前 via iPhone
你参与开源项目为什么呢？我最近写的几个玩具一个 star 都没有，协议都是 unlicense ，但写的过程中我学到了很多东西，所以仍然很开心
|
 |
20
binghongcha 363 天前
之前在学某个知识点，然后看到某个开源项目他刚好不会做这个功能，我就给他提了 pr ，然后合进去了。
感觉还是得平时用到，然后顺手 pr 。 |
 |
21
Jianzs 363 天前
欢迎参与 [Pluto]( https://github.com/pluto-lang/pluto) 呀，一个开发工具项目，帮助个人开发者更轻松地构建云原生应用程序，降低云能力的上手难度。
Pluto 会根据开发者在代码中定义的变量，自动创建与管理必要的云资源组件，蛮有意思的一个项目，还处在非常早期阶段，一起来共建呀。 |
 |
22
qloog 363 天前
一个 Golang 的开发框架： https://github.com/go-eagle/eagle
|
|
23
qloog 363 天前
一个 Golang 的开发框架： https://github.com/go-eagle/eagle ， 欢迎提 PR 或 issue ，tips: 可以从 Readme 之类的开始会更容易一些。
|
 |
24
g1vemep0wer 363 天前
后端不知道，前端我是看到有 bug 有有能力时间修就提个 PR
|
 |
25
dufu1991 363 天前
可以看看我的项目（ https://github.com/any-tdf/stdf ），我也是菜鸟，所以代码和文档写的都非常通俗易懂，提点意见看法或者 BUG 都是可以的。
|
|
26
fen 363 天前
|
 |
27
shakoon 362 天前
我有个同事经常给知名项目提 issue ，但也不是他多厉害，他提的全是文档里的小笔误，没有一个是对代码的改动，但这并不影响他发朋友圈装逼
|
 |
30
artnowben 362 天前
|
 |
31
hankli 362 天前
#4 楼说的很对哦, 从自己常用的项目入手更好.
1.用起来 2.尝试反馈问题 -> issue 3.尝试修问题 -> pr 4. 非常感兴趣 && 有时间-> 修别人提出的 issue |
 |
32
windcode 159 天前
可以了解下这个新项目： https://github.com/KusionStack/karpor
一个围绕多集群搜索、洞察、AI 构建的船新 Kubernetes Dashboard/Explorer ，用 Go + React 写的，不管是前端还是后端都有很多参与的切入点。 另外我按照难度和功能分类整理了一份社区任务清单⬇️，可以帮助新手入门，欢迎上墙（我们把贡献者们张贴到了 README 里） https://github.com/KusionStack/karpor/issues/463 |
Select Language