这是一个创建于 683 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，楼主后端。看到好多大佬的 Github Profile 都好活跃好多数据，看到他们参加了各种各样或大或小的 Project ，或者自己维护了几个一两千 star 的项目，好生羡慕。我也想在 Github 社区无私奉献自己的一份力量，从头开始，从提小 PR 开始，请问有什么好的建议或意见能帮助我更丝滑地进行这个过程吗
 |
1
celeron533 2023-01-03 19:51:14 +08:00
你平日里用什么工具、软件，你写的代码里用了什么库？随便挑一些熟悉的去看看。
|
 |
2
opentrade 2023-01-03 20:06:00 +08:00
关键是能持否？
|
 |
3
saltbo 2023-01-03 20:06:26 +08:00
先用 遇到问题提 Issue 然后根据情况 PR 。具体用什么，可以是 lib ，也可以软件，不论是 cli 还是 app ，都用起来自然就有机会发现问题了
|
 |
4
YVAN7123 2023-01-03 20:07:11 +08:00  1
|
 |
5
jones2000 2023-01-03 21:25:55 +08:00
做开源， 首要你要问自己，你会什么，你能分享给我们哪些你工作中或你在行业里面踩坑的东西， 或总结性的东西。 那些东西是你会的，其他人都不会的东西。 然后用代码写出来基本就可以了。
|
 |
6
amber0317 2023-01-03 22:19:02 +08:00 1
1. 选择一门自己比较熟悉的语言。
2. 既然你对这门语言比较熟悉，那么你一定多少知道一些使用这个语言编写的开源项目。选择一个。 3. 翻阅这个仓库的 Issue 区，直到找到一个你觉得能解决的问题。如果想体验一下流程，可以从修 typo 或者文档开始。 4. 动手，提 PR ，等待合并，并根据 Maintainer 的意见做调整。如果东西比较多（比如要加功能），可以先开个 draft 的 PR ，告诉大家你正在做什么，能解决哪个 issue 。 |
 |
7
rekulas 2023-01-03 22:22:08 +08:00
提个小看法不建议为了 star 去做项目，我认为维护一个几十 star 的软钢需项目比上千 star 的通用轮子项目有意义的多
其实从这个出发点的话发起个很简单了，想想你工作或熟悉的开发领域有什么痛点、不方便的地方，然后用代码来解决 /提高效率，项目就有了 |
|
8
amber0317 2023-01-03 22:23:40 +08:00 via Android
补充一点：在第三点的实践过程中，需要大量阅读原项目的代码。这里可能很容易就放弃了，因为读代码有时候会很痛苦。不过坚持下来就是胜利：读通原项目代码并且知道如何在其上进行扩展，我觉得是很有成就感的事情。
|
 |
9
RRyo 2023-01-03 22:48:57 +08:00
流程上:
先从开 issue 开始, 然后 fork 改 bug/添加需求实现, 提交最好规范一点(angular 规范), 再提 PR, PR 的格式如果项目有模板就对着填写, 然后等待项目维护者 code review 后合入, 可能会有冲突导致无法合入, 这时候需要 rebase, 然后再回复请求 review 项目选择的话建议从你感兴趣并且熟悉语言的项目开始, 不建议从一些明星项目入手, 容易因为各种各样的问题被打击积极性 |
 |
10
Features 2023-01-03 22:59:20 +08:00
我感觉不容易啊
用爱发电是很难的 很多高 star 项目其实是作者在公司的项目衍生出来的开源 国内大部分开源项目应该都是大厂吧，并且通常伴随一定的 KPI 考核？ 独立开发者忙着挣钱养活自己了，哪还有心思去干这些吃力不讨好的事情 你以为自己很无私很伟大，可是有人提 issue ，你没看到或者回复的不好 保证骂的你狗血淋头 |
 |
11
OrkWard 2023-01-04 03:04:11 +08:00
@Features 你这就太片面了，国人做的好项目也非常多，有些人整个项目里面都没中文所以别人都不知道（本来就没什么必要宣传自己的国籍）
确实有很多高 star 项目是大厂开源出来的，但数量绝对没有社区产出的多，但凡稍微了解一点历史…… 我几乎没见过提 issue 还敢骂人的，你这……我不知道怎么说，还是多接触一下社区吧 |
 |
12
LXGMAX 2023-01-04 09:29:10 +08:00
当深度使用一个开源项目 /工具的时候自然会感到它的缺点或 bug ，然后提 issue ，通过阅读源码进一步提 PR ，参与进去
|
 |
13
asdjgfr 2023-01-04 10:07:25 +08:00
同意 12 楼的方法，我就是这样给 mdn 和 element-plus 做贡献的
|
 |
14
mumuy 2023-01-04 10:07:38 +08:00
哈哈哈，我也有 5 个上千 star 的项目，其实就是抓下痛点就好，做出特色。如果非要造轮子除非你的轮子比别人的好很多
|
 |
15
antonius 2023-01-04 11:07:06 +08:00
挑自己熟悉的领域。写测试代码，写新平台的 cmakelists.txt ，改 bug ，pull request 。或者回答社区问题。
|
 |
16
lankunblue 2023-01-04 11:27:05 +08:00
@Features 感觉你是不是有偏见呀。好像不是这样的吧，大家基本还是很友好的吧。
|
|
17
Features 2023-01-04 12:20:54 +08:00
|
 |
18
wuwei12138 2023-01-04 14:04:58 +08:00
@LXGMAX 我经常看到别人这么说，但是我 java 的，使用到的 ssm ，或者 springboot 感觉也没有啥痛点啊。一般来说，这些非常热门的框架很少有 bug 吧
|
 |
19
user7 2023-01-04 15:32:38 +08:00
https://jina.ai/news/how-to-start-your-career-in-open-source
可以看看这篇文章，总结了成为开源社区活跃分子的 5 个步骤 |
|
20
LXGMAX 2023-01-04 18:19:15 +08:00
@wuwei12138 确实，用的人多，出 bug 很快就修复了
|
 |
21
liangnostr 2023-07-30 09:29:52 +08:00
我在用 V2EX 时发现两个痛点：一是当别人说 12 楼是，我不能一下定位到，要一个个数。第二个痛点是，当看到“@wuwei12138 确实，用的人多，出 bug 很快就修复了”这种回复回复别人帖子的时候，也需要费力地去找 @wuwei1213 上面说了什么以便联系上下文。好像发现一个需求了。
|
 |
22
windcode 157 天前
两个方式：
- 寻找贴上 [good first issue] 标签的 issue ，或者直接去这个汇总网站上寻找 https://goodfirstissue.dev/ - github 上搜索 community tasks ，有的 maintainer 为了驱动社区发展会将所有适合贡献的 issue 整理到一起，分门别类，类似这种： https://github.com/KusionStack/karpor/issues/463 |
Select Language