近来我一直在积极参与Google Code-in 2017，为开源组织Wikimedia作出贡献。本文中「畅想资源」将分享一些自己所得到的启发和感想。☺️
背景
去年我也参加了GCI 2016，但当时却只是想着随便玩玩，并没有真正想要投入到社群参与中，最后草草完成四个任务拿到个T恤后便不再继续了。比如可以看到我去年所做的其中一个任务中我连我自己修改相应的代码都没仔细研究，只是囫囵吞枣交差了事。
今年情况却有所不同，我是真心希望可以借这个机会在了解更多开源社区的运作方式，并让自己也尝试投身其中来为其进行贡献。
秉持这样的信念，我在整个过程中增加了和其它社群成员的交流。一开始毋庸置疑十分辛苦，从最开始的如何通过Gerrit上传修复包，如何使用Phabricator讨论任务（Parent Task和Subtask到底谁先谁后😂），再到如何从现有的几十个文件中找到自己需要的文件，再到Git如何回退commit、如何rebase、如何创建follow-up项目，每一项在一开始都是艰钜的挑战。
但在来自社群成员的帮助下，一切却好像又没有这么难了。我希望特别感谢Fomafix最初对我格式准则、不同Change互相关系之间的提点，感谢Framawiki、zhuyifei1999、Xqt在我进行Pywikibot相关任务中的鼓励和帮助，rafidaslam在T183663下对我所写的maintenance的脚本进行的大量更正，以及Jonas Kress对我自己尝试不同方法的鼓励。
正由于今年我的目标不再单纯仅是为完成任务，我没有在因要在几百个错综复杂的文件中找到正确的文件、或要尝试一切来解决一个几毫秒的显示问题或万分之一机率的Bug而苦恼，反而把这些当成一个愉快的学习过程，一个难忘的合作经历。
工欲善其事，必先利其器
从2012年起，我就一直在使用Sublime Text，但不知为何从去年开始，总是每输入几个字符便卡顿，弄得我根本每次在用它编程时便焦虑无比。
好在，就在GCI开始几天前，我发现了微软开发的开源Visual Studio Code，功能更多也更方便，重点是流畅无比，在GCI中做任务时对我帮助很大。
创新VS修补
我们基本可以将GCI上和代码相关的任务分为三类：修复无伤大雅的过时函数、修复小问题/漏洞和新增小功能/小测试。
第一类往往是最容易，同时也是个人认为较无趣的一类。下图便是一个典型例子。
我们绝不能否定这些任务的重要性，甚至从某种程度上来看可以说比其它所有任务都更重要，因为只有有人来贡献这类琐碎的任务，我们的开源项目才能不断被维护更新下去。
不过我个人则更加喜欢剩下两类的项目。修复小问题/小漏洞的任务如下图。
这类任务往往是挑战性和趣味性最适中的任务。解决起来不是太过复杂，任务和导师本身也给予了充足的指示，但解决后却能给人很大的成就感，看到自己也能够为社群修复问题感到很开心。
但不得不说有时候这类的小问题解决起来还真不容易，比如一个简简单单的加入一个 margin-right 就理论上可解决的T178998最后却牵扯出了数个新问题：HTML生成器生成多余回车的T182074以及WikiTextStructure中对相邻div无法进行分割的T182667。就解决这么一个问题，谁又能一开始就能想到会连带出这么多额外问题呢？不过这这是修复这些问题的吸引之处所在。
至于最后一类则如下图。
这类任务难度最大，往往任务介绍并没有给予过多指示，有的甚至只有一个简短的目标。在做的时候最需要和社群的交流以及自己的思考和创造力。比如我在T123885中一步一步对需求的探索，在T173213中对键盘快捷键的讨论等。
从参赛者到（伪）导师
在完成T123885中的脚本创建之后，为解决其中问题并增加更多功能，T183663被创建了。在这些子任务中，我仿佛成为了一个导师，和其它成员一起修改任务描述，思考如何才能最好的将问题和解决方法呈现出来，成为上述第二类任务一样，帮助其它参赛者完成任务。
但正如标题缩写「（伪）导师」，很快我便发现到自己的力不从心。除了过多的子任务让我根本无法即时关注其中每一个之外，我没有类似如zhuyifei1999完整的相关知识，也没有像Framawiki一样丰富的社群参与经验，最后还是只能继续当当参赛者，尽自己所能做贡献。😂
细节强迫症
我相信不少开源社区参与者（包括我）一定是有细节强迫症的。😂
在许多项目中，我曾看到不少参与者为几个px的细微设计差距、几乎毫无差别的流程设计、以至常人毫无感觉的细微问题（比如和无障碍设计相关的）吵架讨论几个月，最后才能对这些小问题达成共识。
这样的操作我是举双手赞成的。只有这样精益求精的精神我们才能设计达成这些社群最初所做成的目标：让每个人都能享受到最好的资源。
承上：永远解决不了的任务
但正是由于这样追求完美的精神，我渐渐发现其实不少问题都因此根本是无法解决的。比如T18691这个想要为一个每个章节标题加入一个链接符号的小小任务从2008年创建后一直讨论到2018年，整整十年都没有结果，更有不少参加者不再参与讨论，更加陷入停滞。类似的烂尾讨论在各语言维基百科讨论中也常常产生。
这样的现象其实便是我们社会永远所在讨论的问题，我们怎样才能在效率和民主之间取得平衡。开源社区就像是一个小小的世界，将真实世界所有的问题同样带入这个虚拟的世界中。
建议
1. WordPress下次也应该参加GCI。😂
2. 下次可以多加一些和代码无关的任务（类似现在这个分享感想的任务），能够吸引更多同学去参加。现时大部分任务的门槛依然过高，相信不少人都像去年的我那样做了几个任务，又看不到什么显著反馈，便悻悻然退出。多加一些诸如编辑维基百科文章又或设计图标的内容可能能够更好的吸引更多人来认识和加入社群。（但这样好像又和「Google Code-in」的Code又没什么关系了😯）
3. 进一步加快反馈时间。我理解Wikimedia中的大部分参与者都是业余时间的「雷锋」，但现时许多任务在完成后都需要1-2天才能得到回馈，而同时又只能申请一个任务来做，对大部分参赛者都很难产生积极回馈，两三天后收到回馈再改又似乎已经忘记当初怎么做的，最后导致趣味消失了很多。
4. 可以创建更多分地区/语言的任务。Google Code-in其中一个优势便是可以吸引来自世界各地的青年前来参与，其所带来对不同地区文化的理解和认识可以很大程度上帮助维基百科和Wikimedia的全球在地化发展，比如我格外喜欢这次批量创建的包含不同语言版本的「为维基共享App制作截图」的一系列任务（见下图，我自己也提交了中文截图），这系列任务不但满足了上述「有显著回馈和成就感」以及「容易上手」的条件，更充分利用了各个参赛者的背景和文化优势，真正做到多样性的贡献和参与。
展望
没参加的赶快去参加！☺️
