6月的武汉很热，在我厚颜无耻的怂恿下，Arch中文社区的依云，从北京不远千里来到武汉，同我们分享交流社区的管理经验和心得体会。
在这之前，我一直对开源大佬怀着深深的敬畏，总觉得他们都是高不可攀的隐世高人。依云的平易近人让我大为感动，也让这次交流分享进行的异常顺畅，我们收益颇丰。
对待社区管理，依云分享了自己的经验。
管理人员的职责是去管理社区，把各种违规行为和离题内容干掉，对于群成员尤其是新手，要引导新手提问，引导用户提供更多的信息，同时引导热心的用户回复。给出一些说明文档和需求攻略让用户去尝试。
仓库管理，Arch中文社区有自己的哲学模式。
加包：
减包：一个包不想维护了提一个请求，没人接手的话14天后会自动删除，最小化维护者的工作量，能自动化就自动化。我们每年都会进行一次大扫除，大家确定不要的包就会用脚本处理掉，保证开源软件的可靠性。
经过依云的分享，颇有一股拨云见日的感觉，对于deepin社区的运营管理和社区仓库的打包维护，有了更多的参考和学习价值。
在这之后，进入了现场提问环节。
对于本次来深度参加分享，你的内心是怎样的？
我刚刚接到邀请的时候还是有些惊讶的，这么多年也就你们找过来了。
对deepin在国内开源社区的发展有什么建议？
社区更多的还是需要让更多的人了解到开源软件的概念是什么，这样社区才能成长，我并不觉得开源软件就反对商业，它并没有限制商业使用，同时它也需要商业公司的支持，商业和开源应该是双赢而非对立的，大部分开源爱好者其实也并不反感商业，只是反感商业公司打着开源的旗号而并不开源。
如何处理带有版权的软件?
不同的软件的版权是不一样的，有些软件允许你再分发，有些软件就比较棘手，用户协议里不允许你再分发，这个时候作为分发方就可以去和对方沟通请求一个分发权限，因为对方不了解和沟通不顺畅导致的不能分发的情况，这个目前也没有很好的解放办法。
社区管理人员之间如果意见未达成一致，接下来要怎么办？
遇到意见不一致的情况就反复讨论，求同存异，尽量的去达成一个共识，因为大家都是理性的，所以达成共识并没有那么困难，如果实在没有办法达成共识，那么这个问题就搁置，之前是怎么样就还是怎么样。
对于社区的开发者维护，有什么好的经验分享，一方面能够扩大社区的开发者群体，另外一方面怎么能够让这些开发者更好和更多的参与到社区建设中来？
像我参与到开源软件以来，我是有自己的驱动力去参与的，有东西坏掉了我就去报bug，我能修的话我就会修好提交，一旦社区的氛围好起来之后，它既不是一个空城，也不会很多人吵来吵去，它会给你一种陪伴和心灵的寄托，就像很多人可能闲着无聊会去刷微博刷推特，我闲着的时候我就去刷社区的群，刷社区的论坛。
至于说如何吸引开发者，首先你要有东西吸引到开发者，有一个满足开发者需求的软件，需要有参与的指引文档，比如说在软件项目主页上我能找到我该如何报bug，我该如何提交pr，要注意什么事情，我能得到的各种资源在哪里，这些文档不需要很标准，但要有。一个新的开发者是不愿意花好几天时间去弄清楚我该如提交补丁这个事情，也不能把别人晾在那里不管，时间久了别人就不理你了。
社区对相对小白的爱好者的态度是什么？
既然深度是为了更广大的普通用户服务的，对小白用户当然是欢迎的，深度和Arch走的道路还是很不一样的，像deepin遇到这样的新手可以提供相应的文档资源，通过这些用户的反馈，总结一下哪些地方没有做好，用心做好自己的软件，让用户可以更顺利的上手。
Deepin国内社区的目标群体应该是哪一类人？
我觉得deepin不能太过于偏技术，因为偏技术的人可能都有自己心仪的发行版了，应该是做好新手用户的同时尽量兼顾一些技术一点的用户，就deepin的用户群体来说，大部分人可能并不关心开源的事情，对deepin来说还是打开市场更重要一些，但是在打开市场的同时不能忽略掉那些老用户，这些用户一定要照顾到，他们可以让更多人知道deepin，在推广上多一份力量。
2个小时的交流虽然短暂，但留给我们的思考却回味无穷，感谢依云的热心分享，今后我们也会逐步加大同国内开源社区的交流，也希望有兴趣的开源社区朋友们和我们取得联系，帮助我们汲取养分不断前行。
