open-source-best-practice
open-source-best-practice copied to clipboard
LinuxSuRen
This is an open-source best practice for those who want to participate in open-source projects 参与开源过程中的一些最佳实践
本次线下聚会由 @LinuxSuRen 发起。 大家可以参考下面的话题来交流： * 开源商业化公司的开源人才招聘 * 招聘渠道 * 人才考核标准 * 任何开源相关 * 吐槽 * 有趣的经历 * 个人体验 * 困惑 * 其他 时间：周末，待定 地址：待定 形式：待定 报名方法： * 在帖子后面留言（表示要报名即可） * 加...
建立“群”、channel 等是一个相对普遍的开源社区（项目）运营手段，所谓“群”的数量甚至会被当做数字化运营的指标之一，在这样的价值导向前提下，运营人员会可能会夸大“群”的价值，以至于滥用“群”。 而在国内，2022 年前后可见的时间范围内，微信几乎是逃不开的一个“私有”渠道。 写给社区运营人员——随着大家接触开源的时间越来越久，可能会加了非常多的微信群，以至于他们无法关注到大部分的群。而微信提供了一个“很有趣”的功能——群折叠，也许你在运营的群多半是“被折叠”了。 ## Bad case 有一些运营人员，为了能够“最大化”地广播某个活动、事件，会同时向很多群进行**无差别**地推送消息。下面给出一些体验很差的案例： * 某 user 或 contributor 发了一个比较重要的信息，结果很快地被**无差别**的**运营消息**刷屏 * 例如：机械地通知社区例会、直播之类信息 ## Good case 为了避免信息爆炸，一些社区会选择分门别类地创建不同的群，并约束大家只在对应的渠道聊相应的话题。一些常见的分类有： * end-user、contributor * 按照不同的 SIG 来划分 * 按照活动来划分的临时群，结束后会解散
对英文不是很熟悉或初次接触开源贡献的人来说，可能会对一些英文缩写词不是很了解具体的含义，下面是部分缩写词以及解释（欢迎补充）： * BTW - by the way * cc * LGTM - look good to me * BDFL - 终身仁慈独裁者（ Benevolent Dictator For Life） * TSC - Technical Steering Committee
作为一名开源布道师，可能会通过如下的方式来传播技术、理念： * 博客文章、教程、业界动态 * 视频录制 * obs * 视频录制（剪辑） * [openshot](https://github.com/OpenShot/openshot-qt) written by Python * [shotcut](https://github.com/mltframework/shotcut) written by C++ * [olive](https://github.com/olive-editor/olive) written by C++ * [kdenlive](https://github.com/KDE/kdenlive) written by C++ (Linux...
备选议题： * DevRel 普及介绍 * DevRel 在国内外的发展概况 * DevRel 和开源的关系 * 什么样的公司（团队）需要全职 DevRel * DevRel 和市场、运营、产品、研发、销售之间的关系、互动 平台：视频号 时间：TBD（某个晚上）
以下是部分人多国内一些所谓“共建”行为的评价 * 很多人在谈“共建者”，但实际却看不到是怎么“共建”的 * 某些人理解的共建就是来给我免费打工 * 反正我只提供平台，你们赶紧来共建 * 在他们的认知里 contributor 都是天神下凡，自己就能解决一切问题 ## 参考链接 * https://mp.weixin.qq.com/s/XjlmOrHcc2ZO-5lCrZBoHg * https://www.bilibili.com/video/BV1Tg411K7KS?p=1
开源与传统的商业行为不同，并不是可以通过造势、华丽的外表、大量资本注入就可以做好的。开源的大部分行为都会被永久留存，那么，在开源运营过程中有哪些可能会是：过度的市场行为（over marketing）、过度的修饰，而这些行为又会给开源社区（项目）本身带来什么影响呢？ ## 案例1 项目 A，在正式版本 v4.0.0 发布前，运营人员希望在项目的 alpha 阶段，通过发布一个功能新特性的预告，让社区成员得以提前体验并反馈。在博客的文章中，有类似如下的一段表述： `除上述功能外，有更多重量级功能会在正式版本发布后在 Release Notes 中详述` 首先，我想补充一个软件迭代以及版本的背景知识。一个软件项目，大致的迭代过程可以是：alpha、beta、rc，等功能稳定后发布 GA 版本。但是，通常会在 feature 开发完成后，才会进入到 alpha；此时，表明了功能基本完成，主要流程可以走通，但不够稳定、可能会有 bug 出现。因此，大概率不太会出现 alpha 版本之后还会有**更多重量级功能**进入到正式版本中。 其次，即使是想要给读者留下悬念，以吸引大家的注意力，但也应该能够自圆其说、确保语言表述不是错误的。 细心的开源参与者，是希望参与到严谨的开源社区（项目）中来。而对于开源项目的用户，也不要“轻易”相信“鼓吹”式宣传文案。 在这个案例中，我呼吁开源运营人员尽量在了解软件发布基本常识，并尊重事实的前提下，再发挥文字的“修饰”效果。宣传文案虽然不需要像源代码那么严谨，但至少要确保实事求是，不打插边球。
播客： - [No.16: 听过来人一句劝，合规真的很重要！](https://www.ximalaya.com/sound/484344060) - [No.13：开源项目的知识产权](https://www.ximalaya.com/sound/460687369) 文章： - [看看中国法院是怎么对待GPL协议的](https://mp.weixin.qq.com/s/zj2j5jWULDEAJPVscrNWUg) - [开源软件、自由软件、Copyleft、CC都是啥，傻傻分不清楚？](https://mp.weixin.qq.com/s/tKr8swvZTZTWjBWMJ4bSdg) - [EPL许可证人话翻译](https://mp.weixin.qq.com/s/zRFBbcIOkny5d9iGgU4lGw) - [人话解读GPLv3](https://mp.weixin.qq.com/s/muPDVThX5S4vsXuM5PEoIw)
* Nebula Graph - [故事从三年前的今天开始，它开源了…](https://mp.weixin.qq.com/s/pKsVF_rpBAK6pVA8ffvyfw)
Metadata
Owner
Metadata
This is an open-source best practice for those who want to participate in open-source projects 参与开源过程中的一些最佳实践