Skip to content

Commit 8f636e5

Browse files
committed
[marketing] done
1 parent ab01cb5 commit 8f636e5

File tree

5 files changed

+62
-7
lines changed

5 files changed

+62
-7
lines changed

chapters/07-github-marketing.md

Lines changed: 22 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -99,7 +99,11 @@ numbers, objects, strings, etc. Lodash’s modular methods are great for:
9999
- Manipulating & testing values
100100
- Creating composite functions
101101

102-
你会怎么写?
102+
你会怎么写?脸皮够厚的话,可以直接写一下,与其它项目的对比,blabla:
103+
104+
![对比其它项目](./img/comparison.png)
105+
106+
当然了,这种事不能太过,要不是会招来一堆黑。
103107

104108
### 安装及hello, world 示例
105109

@@ -160,6 +164,8 @@ WTF!
160164

161165
上图是使用了 jsdoc 的 Lodash 示例。
162166

167+
除了上面的示例,我们还可以录制一些视频,写一些文章说明项目的思考、架构等等。
168+
163169
### 更多的示例程序
164170

165171
示例代码本身也是文档的一部分,不要问我为什么~~
@@ -170,11 +176,25 @@ WTF!
170176

171177
没有这么多示例,敢说自己是好用的开源项目?
172178

173-
### 编写技术文章
179+
### 编写技术文章、书籍
174180

181+
到目前为止,我们做了一系列 markdown 相关的工作,却也还没有结束。要知道只有真正写过一系列开源项目的人,才能体会到什么是 markdown 程序员~~
175182

183+
官方文档,一般要以比较正式的口吻来描述过程,这种写法相当的压抑。如果要用轻松诙谐的口气,那么就可以写一系列的技术文章。假如这是一个前端框架,那么我们可以介绍它如何与某个后端框架配合使用;又或者是,它与某个框架的对比等等。
184+
185+
好了,一切顺利了,那么下一步就是吸引更多的人参与到项目上来了。
176186

177187
鼓励、吸引贡献者
178188
---
179189

190+
要吸引其它开发人员来到你的项目,不是一件容易的事。
191+
192+
你需要不断地鼓励他/她们,并适时地帮他/她们解决问题,以避免他/她们在提 pull request 的过程中放弃了。这一点特别的有意思,当有一个开发人员发现了项目中的 bug,那么他/她会尝试去解决这个问题。与此同时,他/她还会为你的项目带来 pull request,但是在这个过程中,因为测试等等的问题,可能会阻碍他的 PR。这个时候,就需要我们主要去提示/教他们怎么做,又或者是帮他/她们解决完剩下的问题。那么,下次他/她提一个 PR 的时候,他/她就能解决问题了。
193+
194+
这一点可以在 README,以及介绍上体现:
195+
196+
![Feel free to contribute!](feel-free-to.png)
197+
198+
哪怕只是一个错误字的 PR,那么你也可以 merge,啊哈哈~。然后,就有人帮你宣传了,『我给 xxx 项目一个 PR 了』。刚毕业的时候,我也是从这种类型的 PR 做起的~~
199+
180200

github-roam.md

Lines changed: 22 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1685,7 +1685,11 @@ numbers, objects, strings, etc. Lodash’s modular methods are great for:
16851685
- Manipulating & testing values
16861686
- Creating composite functions
16871687

1688-
你会怎么写?
1688+
你会怎么写?脸皮够厚的话,可以直接写一下,与其它项目的对比,blabla:
1689+
1690+
![对比其它项目](./img/comparison.png)
1691+
1692+
当然了,这种事不能太过,要不是会招来一堆黑。
16891693

16901694
### 安装及hello, world 示例
16911695

@@ -1746,6 +1750,8 @@ WTF!
17461750

17471751
上图是使用了 jsdoc 的 Lodash 示例。
17481752

1753+
除了上面的示例,我们还可以录制一些视频,写一些文章说明项目的思考、架构等等。
1754+
17491755
### 更多的示例程序
17501756

17511757
示例代码本身也是文档的一部分,不要问我为什么~~
@@ -1756,13 +1762,27 @@ WTF!
17561762

17571763
没有这么多示例,敢说自己是好用的开源项目?
17581764

1759-
### 编写技术文章
1765+
### 编写技术文章、书籍
17601766

1767+
到目前为止,我们做了一系列 markdown 相关的工作,却也还没有结束。要知道只有真正写过一系列开源项目的人,才能体会到什么是 markdown 程序员~~
17611768

1769+
官方文档,一般要以比较正式的口吻来描述过程,这种写法相当的压抑。如果要用轻松诙谐的口气,那么就可以写一系列的技术文章。假如这是一个前端框架,那么我们可以介绍它如何与某个后端框架配合使用;又或者是,它与某个框架的对比等等。
1770+
1771+
好了,一切顺利了,那么下一步就是吸引更多的人参与到项目上来了。
17621772

17631773
鼓励、吸引贡献者
17641774
---
17651775

1776+
要吸引其它开发人员来到你的项目,不是一件容易的事。
1777+
1778+
你需要不断地鼓励他/她们,并适时地帮他/她们解决问题,以避免他/她们在提 pull request 的过程中放弃了。这一点特别的有意思,当有一个开发人员发现了项目中的 bug,那么他/她会尝试去解决这个问题。与此同时,他/她还会为你的项目带来 pull request,但是在这个过程中,因为测试等等的问题,可能会阻碍他的 PR。这个时候,就需要我们主要去提示/教他们怎么做,又或者是帮他/她们解决完剩下的问题。那么,下次他/她提一个 PR 的时候,他/她就能解决问题了。
1779+
1780+
这一点可以在 README,以及介绍上体现:
1781+
1782+
![Feel free to contribute!](feel-free-to.png)
1783+
1784+
哪怕只是一个错误字的 PR,那么你也可以 merge,啊哈哈~。然后,就有人帮你宣传了,『我给 xxx 项目一个 PR 了』。刚毕业的时候,我也是从这种类型的 PR 做起的~~
1785+
17661786

17671787

17681788
开源项目维护

img/comparison.png

262 KB
Loading

img/feel-free-to.png

193 KB
Loading

index.html

Lines changed: 18 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -157,7 +157,7 @@ <h1>GitHub 漫游指南</h1>
157157
<li><a href="#技术文档">技术文档</a><ul>
158158
<li><a href="#技术文档-1">技术文档</a></li>
159159
<li><a href="#更多的示例程序">更多的示例程序</a></li>
160-
<li><a href="#编写技术文章">编写技术文章</a></li>
160+
<li><a href="#编写技术文章书籍">编写技术文章、书籍</a></li>
161161
</ul></li>
162162
<li><a href="#鼓励吸引贡献者">鼓励、吸引贡献者</a></li>
163163
</ul></li>
@@ -1657,7 +1657,11 @@ <h3 id="它有什么特性">它有什么特性</h3>
16571657
<li>Manipulating &amp; testing values</li>
16581658
<li>Creating composite functions</li>
16591659
</ul>
1660-
<p>你会怎么写?</p>
1660+
<p>你会怎么写?脸皮够厚的话,可以直接写一下,与其它项目的对比,blabla:</p>
1661+
<figure>
1662+
<img src="./img/comparison.png" alt="对比其它项目" /><figcaption>对比其它项目</figcaption>
1663+
</figure>
1664+
<p>当然了,这种事不能太过,要不是会招来一堆黑。</p>
16611665
<h3 id="安装及hello-world-示例">安装及hello, world 示例</h3>
16621666
<p>在我们看完了上面的介绍之后,紧接着接一个 hello, world 的示例。在运行 hello, world 之前,我们可能需要一些额外的安装工作,如:</p>
16631667
<pre><code>npm install koa</code></pre>
@@ -1697,15 +1701,26 @@ <h3 id="技术文档-1">技术文档</h3>
16971701
<img src="./img/lodash-code-example.png" alt="Lodash 示例" /><figcaption>Lodash 示例</figcaption>
16981702
</figure>
16991703
<p>上图是使用了 jsdoc 的 Lodash 示例。</p>
1704+
<p>除了上面的示例,我们还可以录制一些视频,写一些文章说明项目的思考、架构等等。</p>
17001705
<h3 id="更多的示例程序">更多的示例程序</h3>
17011706
<p>示例代码本身也是文档的一部分,不要问我为什么~~。</p>
17021707
<p>反正,除了一个 hello, world,你还要有各种场景下的示例:</p>
17031708
<figure>
17041709
<img src="./img/redux-examples.png" alt="Redux" /><figcaption>Redux</figcaption>
17051710
</figure>
17061711
<p>没有这么多示例,敢说自己是好用的开源项目?</p>
1707-
<h3 id="编写技术文章">编写技术文章</h3>
1712+
<h3 id="编写技术文章书籍">编写技术文章、书籍</h3>
1713+
<p>到目前为止,我们做了一系列 markdown 相关的工作,却也还没有结束。要知道只有真正写过一系列开源项目的人,才能体会到什么是 markdown 程序员~~。</p>
1714+
<p>官方文档,一般要以比较正式的口吻来描述过程,这种写法相当的压抑。如果要用轻松诙谐的口气,那么就可以写一系列的技术文章。假如这是一个前端框架,那么我们可以介绍它如何与某个后端框架配合使用;又或者是,它与某个框架的对比等等。</p>
1715+
<p>好了,一切顺利了,那么下一步就是吸引更多的人参与到项目上来了。</p>
17081716
<h2 id="鼓励吸引贡献者">鼓励、吸引贡献者</h2>
1717+
<p>要吸引其它开发人员来到你的项目,不是一件容易的事。</p>
1718+
<p>你需要不断地鼓励他/她们,并适时地帮他/她们解决问题,以避免他/她们在提 pull request 的过程中放弃了。这一点特别的有意思,当有一个开发人员发现了项目中的 bug,那么他/她会尝试去解决这个问题。与此同时,他/她还会为你的项目带来 pull request,但是在这个过程中,因为测试等等的问题,可能会阻碍他的 PR。这个时候,就需要我们主要去提示/教他们怎么做,又或者是帮他/她们解决完剩下的问题。那么,下次他/她提一个 PR 的时候,他/她就能解决问题了。</p>
1719+
<p>这一点可以在 README,以及介绍上体现:</p>
1720+
<figure>
1721+
<img src="feel-free-to.png" alt="Feel free to contribute!" /><figcaption>Feel free to contribute!</figcaption>
1722+
</figure>
1723+
<p>哪怕只是一个错误字的 PR,那么你也可以 merge,啊哈哈~。然后,就有人帮你宣传了,『我给 xxx 项目一个 PR 了』。刚毕业的时候,我也是从这种类型的 PR 做起的~~。</p>
17091724
<h1 id="开源项目维护">开源项目维护</h1>
17101725
<h1 id="如何以正确的姿势阅读开源软件代码">如何以“正确的姿势”阅读开源软件代码</h1>
17111726
<blockquote>

0 commit comments

Comments
 (0)