思考：该如何运营你的开源用户（contributors）“群”

Nobody has claimed this yet.

建立“群”、channel 等是一个相对普遍的开源社区（项目）运营手段，所谓“群”的数量甚至会被当做数字化运营的指标之一，在这样的价值导向前提下，运营人员会可能会夸大“群”的价值，以至于滥用“群”。

而在国内，2022 年前后可见的时间范围内，微信几乎是逃不开的一个“私有”渠道。

写给社区运营人员——随着大家接触开源的时间越来越久，可能会加了非常多的微信群，以至于他们无法关注到大部分的群。而微信提供了一个“很有趣”的功能——群折叠，也许你在运营的群多半是“被折叠”了。

## Bad case
有一些运营人员，为了能够“最大化”地广播某个活动、事件，会同时向很多群进行**无差别**地推送消息。下面给出一些体验很差的案例：

* 某 user 或 contributor 发了一个比较重要的信息，结果很快地被**无差别**的**运营消息**刷屏
* 例如：机械地通知社区例会、直播之类信息

## Good case
为了避免信息爆炸，一些社区会选择分门别类地创建不同的群，并约束大家只在对应的渠道聊相应的话题。一些常见的分类有：

* end-user、contributor
* 按照不同的 SIG 来划分
* 按照活动来划分的临时群，结束后会解散

No file, test, or entry point is named; the issue is a discussion of community-channel practices rather than a defined repository change. Confirm the intended article location, scope, and acceptance criteria before starting, since the issue does not specify what would count as done.

Written by the indexing model from the issue text.