改善群组成员请求的流程

功能
,
22

So, to start with, this is about adding a link into the PM that gets sent to the group owner when someone requests group membership, right? The link should lead to the respective group’s page (groups/<groupname>), open the “add members” modal and ideally also already add the new users username into the modal so that the group owner only needs to press “+ Add”.

The last bits seems to be the difficult part:

  • is there a URL to navigate to the modal or would it have to be implemented as well?
  • even if I can open the modal with a URL, I suppose that there is currently no way of adding a username to that URL, right?
2 个赞
23

最近我们处理了很多群组成员资格请求，而当前的工作流程给我们带来了一些麻烦。我有一个想法，可以显著地改进它，而且（希望）很容易实现。

当前工作流程

  1. 用户点击 image 按钮
  2. 用户被加入一个队列，可以通过 /g/group-name/requests 访问，并且会生成一封包含以下文本的私信：
    • @group-name 的成员资格请求
      xxxxxx 用户输入的文本（使用群组设置中的模板）
    • 这会发送给最近活跃的群组所有者（不确定此如何计算）
  3. 群组所有者看到私信
    • 这包括消息文本上方一个“处理成员资格请求”的链接
      （链接到 /g/group-name/requests?filter=username）
  4. 其中一位群组所有者处理该请求
  5. 生成一封新的私信
    • 您已被接受加入 @group-name（如果被拒绝则为“您已被拒绝加入 @group-name”）
      您加入 @fci-members 的请求已被接受，您现在是该群组的成员。
    • 这会从群组所有者（仅处理请求的那一位）发送给用户。

当前工作流程的问题

  1. 其他群组所有者无法轻松地判断请求是否已被处理

    • 他们需要点击进入 /g/group-name/requests?filter=username
    • 如果已被处理，您会看到“该群组没有成员资格请求。”
      • 没有迹象表明他们已被接受或拒绝
      • 要发现这一点，他们必须访问用户的个人资料并进行查找（或搜索群组）

  2. 批准/拒绝用户的群组所有者无法轻松地添加/修改生成的私信

    • 它会被放入他们的已发送箱（眼不见，心不烦）
    • 这错失了所有者与新成员之间进行积极互动的机会

  3. （次要问题）有两个私信主题（只需要一个）

建议的更改

您可能已经猜到了！

将第二封私信改为回复第一封私信，而不是发送一条全新的消息。

这将很好地解决所有 3 个问题，闭合通信循环，为所有群组所有者提供良好的可见性，最大限度地减少不必要的通知，并促进积极的社区互动。

您怎么看？

5 个赞
24

我们遇到了类似的问题：群组所有者联系我，想了解为什么他们会进入请求页面却发现它是空的（因为别人已经先接受了请求）。

我相信 Nathan 的解决方案会是个好方法。它不会过多地改变用户的操作流程，并且能有效地消除混淆。

在此期间，我建议群组负责人留下痕迹：比如给消息点赞，以便其他社区所有者可以看到，或者留下一条简短的欢迎消息。

3 个赞
29

我认为Discourse团队已经同意了——这似乎是它现在的样子！

不确定这个改动是什么时候悄悄加入的，但我很高兴 :clap:

5 个赞
30
7 个赞