上周,我在这里发布了公司对Meta和主持人做出回应的承诺。如果您还没有阅读它,建议您在阅读本书之前先阅读,因为它提供了公司承诺的更高层次的看法:

它介绍了管理社区的新流程CM团队已创建的反馈;
提出了一个测试该过程的时间表,时间为2020年3月16日至2020年4月30日;
它概述了围绕该测试的计划沟通。

如该帖子中所承诺的那样,此指南包含一些指导,以确保主持人了解何时升级他们认为需要由工作人员解决的问题,何时不解决。它还为整个社区提供了一些指导,说明应将哪些帖子作为升级的候选人提请主持人注意。该指南适用于测试的持续时间,一旦完成,将重新审查和更新。
主持人团队中有一个姊妹职位,其中包括有关主持人如何从那里升级问题的指南。整个网络的主持人也可以使用该帖子来讨论如何处理升级请求,或者特定帖子是否可以成为优秀的候选人。
是什么使得优秀的候选人可以升级?
新问题:
对于测试期间发布的任何新问题(从2020年3月16日开始发布的任何问题),请考虑以下问题:

该问题是否是功能请求,看起来像它具有社区支持吗?
是否报告了其他人能够复制的错误报告?
问题是否仅由员工完全回答?

如果您回答“是”,至少以上之一,那么该问题很适合升级。
较老的问题:
我们意识到,在网络上的各个Meta网站上,有很多出色的帖子尚未得到员工的解决-其中有些也是很久以前发布的。为了在让CM团队被所有这些工作淹没和完全将他们排除在测试之外之间取得平衡,我们建议您将精力集中在重现旧问题,这些旧问题与社区经理只能回答的问题有关,或有关各个产品团队目前正在研究的事情(这使我们能够轻松找到这些较早的讨论,以便我们可以将其用作研究的一部分)。
因此,如果某个帖子符合新问题的指导以上内容,但已在测试开始之前发布(2020年3月16日之前),它还需要落入以下类别之一才能成为升级的良好候选者:


特定的关注点:从政策到社区指导,只有社区经理才能做出合理回应的任何事情。例如,这包括用于帮助中心页面的调整,以及不需要开发时间的任何此类修改。

关闭用户体验:任何与问题解决的一般经验和技巧有关的帖子;当涉及到当前系统时,用户面临着作为问询者,应答者,策展人或主持人的问题;任何功能请求或建议等(在我们的Q1路线图中提到,并且在共享Q2的计划时还会有更多详细信息。

网站工作原理的用户指南:有关教育用户如何操作的任何帖子Stack Overflow的工作原理,如何提出好的问题,如何给出好的答案,针对策展人的最佳实践等。特定于特定用户群(新问者,新答题​​人,新策展人等​​)的帖子也是不错的候选人(我们'目前仍在从事一系列电子邮件工作,以在系统的各个部分上教育用户,但是此反馈对于将来的工作(例如更好的现场用户入职)也将是有用的。

问题追随:有专门的元帖子来征求有关此方面即将开展的工作的反馈,但是有关问题偏好,跟踪能力,针对您感兴趣的问题得到通知的能力,能力的任何先前功能要求或一般反馈/沮丧关闭通知/噪音等都是不错的选择。

Oneboxing:GitHub / Stack Overflow for Teams集成的oneboxing功能是在考虑其他集成的基础上构建的,也将其推广到公共问答网站。常见问题解答中的所有问题都是不错的选择,例如在问题中包括代码片段,与其他开发工具集成,随着代码或问题的发展而保持问题准确性的问题等。

工作应用程序管理:我们正在应用程序历史记录页面上做一些工作,因此有关更好地管理Jobs应用程序的任何帖子都非常适合作为候选人。所有网络站点,即使有一些简化(就像新的“问问题”页面发生的情况一样)。除了这些较大的存储桶之外,对于网络中的每个非SO(或MSE)站点,CM团队还希望看到您的社区已经要求启用此特殊功能一段时间(Mathjax,语法突出显示等) ),或将对您的新提问者有所帮助的特定警告-因此,请为我们提供您网站上针对特定网站的出色自定义功能的前5名,并确保其得分为正。请注意,需要开发时间且仅适用于您的网站的功能不太可能被赋予较高的优先级。
希望如此,这是多余的,但只是为了清楚起见:不要重新发布旧帖子只是为了使他们能够引起人们的注意,以此作为玩这个系统的一种方式。
普通用户如何提名帖子以引起员工的关注?
如果问题符合上述条件,请使用“需要主持人干预”选项标记该帖子以引起主持人注意,并确保提供指向该帖子的链接以供参考。尽可能清楚地说明为什么您认为该帖子是不错的候选人。
为防止主持人使用标志超载,请避免大举狂欢。尽管CM团队(在心理上……?)已经准备好迎接可能在希望开始的几周后消退的第一波浪,但我们想提醒您,主持人将是与之打交道的第一线人这些。 CM将与mod一起使用,以确保这不会导致工作量的大幅增加,并尽力减轻这种情况-但我们也依赖于您不要用标记请求轰炸它们。
主持人如何升级帖子以引起工作人员的注意?
主持人如何处理提名要升级的帖子的标志?
请参阅上面的指南,了解如何判断帖子是否适合升级。除此之外,只需像处理其他标志一样使用您的判断即可。在某些情况下,您可能希望将标记标记为有帮助,但又不想添加标记-很好:再次使用您的最佳判断。如果您不添加标签,请尝试使用标志响应字段来解释原因,以便标志者还可以获取有关决策的一些信息。
如上所述,很可能会有很大的初始波动该职位被标记为升级候选人。考虑到这一点,主持人可能还会增加相应数量的虚假帖子,这很好。
如果您不确定,请与您的同伴谈谈,或者随意在教师休息室对CM进行ping,以了解他们的想法。如果主持人在问题升级过度而不是在问题升级方面犯错是可以的:如果CM团队确定某些问题可以在无需提升人员的情况下得到回答,那么这是将主持人指向该信息的好机会
如果您通过添加status-review标签来升级问题,但是有某种原因导致该问题“得到解决” –也许社区中的某人实际上可以回答它,并且这样做;也许错误确实是用户方面的问题;等等-请在教师休息室对CM进行ping操作,以说明情况。然后,我们将与您一起解决该特定问题的处理方法(至少可能意味着删除标签)。
好吧,主持人如何实际升级帖子,然后?
升级帖子就像添加status-review标签一样简单。这样做可以确保通过提要来提取帖子,并将该问题提交到我们的内部跟踪系统中。
如果您是主持人,请参阅上面的部分,其中描述了哪些适合升级的优秀候选人-如果职位合适,添加标签(普通用户无需进行标记过程)。
如果帖子已经具有状态审核标签,请在教师休息室中对CM进行ping操作,然后将其添加到我们的
职位升级后会发生什么?
CM团队将对帖子进行分类和优先级排序,然后将其传递给相关团队,该团队可以是CM或任何相关产品团队。然后,它将被用于该团队现有的每周工作流程中,目的是在团队能够设法尽快得到答复时。
请注意,所做的承诺是尽可能多地回复帖子-这可能意味着回答或发表评论,或添加其他状态标签。这并不一定意味着实现功能请求或修复错误-希望有时会发生。
有些帖子可能仍未回复:我们将跟踪所有这些数字并报告给他们一旦测试结束。这将帮助我们为可以回复的帖子以及回复的速度定义目标。然后,我们将每季度审查这些目标,以确保我们设定切合实际的目标并实现这些目标。

我们希望本指南清晰明了,并相信它将帮助我们实现新流程中概述的目标我们正在测试。它还应回答该原始帖子中的大多数悬而未决的问题。由于这对我们内部和所有社区和主持人来说都是一次考验,请随时要求澄清以下不清楚或令人困惑的问题。也欢迎在调整过程和/或指南时考虑反馈意见。

评论

是否可以在应该在相对较短的时间内解决的问题上标记旧帖子?我对代码一无所知:直到今天,用于在代码块内部进行搜索的搜索词,应该像在/ help / searching中添加1-2个句子一样容易。

所有这些问题(当前标记为状态审核)会发生什么?它们一开始会被丢弃到您的饲料中吗?您会自动从所有标签中删除该标签,然后手动将其重新添加到其中一些标签中吗?

@ S.S.Anne是的,请随时举报这些人-只是不要大规模这样做。

@ Randal'Thor他们不会被扔进这项测试的,不。测试之后,我们将确定我们对它们的处理方式(重新标记,使用其他标记或其他标记)

我要补充一点,@ Randal'Thor,社区开发团队已经在跟踪其中许多内容。

@JNat我认为解决这些问题非常重要,可能是删除当前未跟踪的帖子的标签,并为那些正在跟踪的帖子保留标签(希望通过脚本而不是手动进行:))。不过,暂时让它们悬而未决是合理的。

在已经发布的那些问题中,对于那些除了状态检查之外尚未实现且未被拒绝或推迟的带有标签的标签,该怎么办? (例如,状态已计划,状态已复制等)?

“是否是其他人能够复制的错误报告?”存在一个问题。是有些人很快就无法看到并重现错误,并且投票否决或关闭无复制权;没有意识到在一个以上的位置上有多个服务器,并且用户端的软件有时也很重要。在某些部署情况下,站点的修订号或API内部版本号会引起评论者的误解。

您是否有一个(简化的)流程图?您的帖子中有很多信息,但我怀疑其中的核心要比看起来简单得多,宁愿避免造成混淆。

让我们将它们留在测试中,@ SonictheAnonymousHedgehog:只要有这些标签,它们就很可能在某人的关注范围内。测试结束后,我们将重新评估并决定下一步该怎么做。

“最适合升级的因素”部分是最相关的@Mast。但是,我将看看今天是否可以花一些时间将其放入流程图中(如果没有,我将在下周初尝试)。

稍微编辑问题以解决该问题,@ S.S.Anne

“针对各个产品团队当前正在处理的事情”也许是我略过了,或者是主题列表,但是主持人应该如何知道产品团队正在做什么?

它是下面的列表,是的,@ Braiam :)

@Marijn,如果不进行升级的话,他们不太可能受到较少的关注,因为员工仍在同样地查看MSO和MSE,并且可以自己添加标签-但是您也可以将其标记为升级,是的,因为它广受好评,并且其他人也可以复制(这样我们可以确保它被考虑在内)。

#1 楼

我想提出一个方面,希望人们对此保持敏感。

允许MSE主持人作为功能请求者获得此标签的仲裁者,从而引起SE的注意,并给予力量由Stack Exchange选择作为主持人的三个用户。他们不是由MSE用户民主选举产生的;他们被任命。而且,选择它们是为了缓和MSE,而不是为了优先处理最重要的功能;但是此策略也使他们成为功能请求的网守。 (从某种意义上说,MSE mods与MSO mods有所不同。)

该帖子说明了要考虑标签的帖子的资格标准以及提名帖子供mods考虑的过程,但为他们留出了很大的酌处权,关于标签将如何使用和不使用。

这有可能在将来引起摩擦。可能是将MSE mods设置为接收用户的不满,这些用户对他们提名的帖子没有被选中接收标签感到不满意,并可能迫使MSE mods在他们不愿或不应该得到的辩论中采取立场(强迫他们接受或拒绝建议的标签)。

我并不是说您不应该这样做。您正在寻找过滤哪些帖子会受到关注并使公司参与Meta的可行性的好方法。现在测试该过程似乎是合理的。但是,我希望如果这成为一个长期的过程,那么可以考虑一下一个更大程度地涉及社区的过程。

评论


建议:特别是对于MSE,也许我们可以创建一个大的meta线程,其中所有答案都是关于哪些帖子应提名为状态审核的建议。答案达到一定分数后,主持人将标签添加到链接的帖子中(并删除该答案以腾出空间让其他人上升)。这将通过从非民选的版主决策责任更广泛的社区。

–兰德·托尔
20-3-12在23:13

@ Randal'Thor我认为这会使事情朝相反的方向摇摆太多。我们绝对仍然希望采取一些措施,以防止仅由纯粹的受欢迎程度决定“重要性”。否则,我们也可能会完全忽略MSE和子元数据问题,而只关注MSO问题。

– goldPseudo
20 Mar 12 '20 at 23:18

我与允许MSE主持人这个责任不太关注,不仅是因为我个人也相信他们,因为适度是不是来自社区的评论自由,主持人是否任命或选举。我真的怀疑,MSE mods和整个社区同意标记的东西之间会有很大的区别。另一方面,出于此处所述的原因,我绝对担心要让MSE主持人承担此责任。

–布莱恩·克劳斯(Bryan Krause)
20-3-12在23:24

值得注意的是,MSE主持人的主要目的主要是减少SE员工对网站进行审核的工作量。在2018年11月之前,该网站完全由工作人员主持。 (例如,MSE模组没有发言权的示例,它位于此处的功能标签中,因为它是整个网络范围内的,而不是每个站点的。)

–好奇号刺猬索尼克
20-3-12在23:42



实际上,我们可以设置这些标签。通常,我们通常不这样做,因为我们对所涉及的标志的实际状态没有足够的了解。

–游侠怪胎♦
20 Mar 13 '20 at 0:27

如果这篇文章是先发制人地指责MSE mods不称职或试图使他们免受不幸之苦,那么我无法下定决心。我选择了第一种解释,因为这似乎是最强烈的信息。这篇文章对此我有不赞成。如果可以对其进行编辑以使其意图更加明显,我很乐意再次访问。

–rene
20 Mar 13 '20 at 7:35

@rene我这篇文章的解读是,这是关于MSE MODS的自己,他们的能力或以其他方式,而只是给予非选举产生的官员个个有决定权的原则,没有从用户的整个网络的功能要求是值得提出来已实施。即使确定当前的三人组都能做到这一点,您也看不出来为什么这可能不是一个好外观吗?

–兰德·托尔
20 Mar 13 '20 at 8:42

@ Randal'Thor不,即使您有详尽的解释,也很感激,但我仍然不明白为什么这可能不是一个好样子。仍然感觉像是对mod的刺探,一般来说,特别是在MSE上,总是会遭到我的反对。

–rene
20 Mar 13 '20 at 9:04

@rene OK,假设您是最近对SE失去了很多信任的人之一,请进行实验:假设公司做出了一些更糟糕的决定,Meta mods对象,SE会立即将其全部解雇并将其替换为毫无疑问将在所有方面为公司提供支持。但是已经有一个既定的策略,将状态审核标记完全保留给Meta mod。您认为这是一件坏事吗?

–兰德·托尔
20-3-13在9:07

我得到了这样的回答被提出的问题,关于超载版主的可能性,这样的事实,他们任命,没有当选。重新超载:如文章所述,CM将与主持人紧密合作,以便我们可以根据需要调整方法并尽可能地帮助Mod。

– JNat♦
20-3-13在11:20



(续)重新当选不是:我想强调的事实,这是一个考验,而且它的结论后,我们就可以重新评估我们将如何工作向前发展。另外,与该问题相关的Mod团队的姊妹职位是一个地方,网络上的所有Mod都可以在此讨论如何处理某些标志,或者这些职位是否是优秀的候选人,等等。因此,MSE Mod仍有空间还不具备所有功能:)(将进行编辑以使其更明显)

– JNat♦
20-3-13在11:20

@rene,我绝对不是要指责MSE mod或暗示任何有关它们的信息。我非常尊重他们。相反,我想提出一个有关该原则的观点。

– D.W.
20 Mar 15 '20在22:46

@JNat指定主持人的考试于2018年11月开始。该考试应该花多长时间?

–好奇号刺猬索尼克
20 Mar 16 '20在20:07

Dunno,@ SonictheAnonymousHedgehog。我在上面说“这是一个测试”,是对升级程序的参考,而不是那样。

– JNat♦
20 Mar 16 '20 at 20:13

@FedericoPoloni绝大多数主持人的举动是没有争议的(除非人们想像巨魔一样毫无争议地提出争议)。评论总是短暂的,因此删除它们会减少监督。封闭式问题可以通过表决重新开始。如果担心审核,用户可以(并且确实)在Meta上提出问题。

–布莱恩·克劳斯(Bryan Krause)
20 Mar 27 '20 at 17:45

#2 楼


,我们将其手动添加到我们的系统中


您是否有机会公开具有优先级的任务列表?看到它会很高兴。

评论


是的,如果只是为了避免人们一遍又一遍地标记相同的内容。

–耶拿
20-3-13在7:18

在测试期间没有计划。我同意这样做会有一些好处,但是如果这取决于我,那就不知道了。我们将看到测试带来的好处,然后从那里继续。

– JNat♦
20 Mar 13 '20 at 11:29

@JNat感谢您的回复。等着瞧 (:

– Suvitruf-Andrei Apanasik
20-3-13在11:38

#3 楼


我们希望这份指导很明确


乍一看,就像那样。如果确实足够,那么该实验将证明一切。那就是敏捷的全部要点:不要以为您已经掌握了一切。提供一些内容,然后开始尝试。适应,重复。

完全按照此处所述。至少在我看来,考虑到您在此处提供给我们的信息,我很乐意进入这一阶段。

很明显,该提案已经涉及了很多想法。其背后的承诺水平令人惊讶。

从这个角度来看,我现在最担心的是:最初的浪潮确实很大,并且负担了做出决策的人员的负担。

因此:我们的用户在这里应该非常尽责,而从事这些工作的用户应该在“太多”到来时告知我们。承认可利用的资源有限是没有耻辱的。因此,每个人都在这里管理期望!

最后,对于社区来说,问题是:我们是否需要一些硬性规则来确定“社区支持”方面?像是一定时期内最少数量的投票? (而且我认为:这一方面值得讨论,但是作为DUP的内容已经关闭,请参见如何在Meta网站上确定共识?)

评论


我认为设定任何特定的硬性规则将很困难。有些问题引起了很多关注和投票,但是在它们成为有用的反馈之前,确实需要从社区进行更多的迭代(另一种思考方式是,这是一个被标记的问题,但实际上可能是一个很好的答案需要审查)。其他的则非常简单,甚至可能有些无聊,例如CSS调整的意外结果。对于那些我认为最好尽快升级的人,因为它很可能可以追溯到最近的提交并可以快速解决,而不需要更多反馈。

–布莱恩·克劳斯(Bryan Krause)
20 Mar 13 '20 at 1:38

@BryanKrause:此外,当社区规模(以及投票/分数)发生巨大变化时,网络上的“硬性规定”毫无意义。

– V2Blast
20 Mar 13 '20 3:27

是的,对不起。我用“我们”来专门指这个地方。

–GhostCat
20-3-13在4:19

正如您所说,我对这篇文章的评价是+1,因为a)认为它已经考虑了很多想法,但是b)并不认为这种想法意味着设计是完美的,并且工作已经完成。

–熊佳亚诺夫
20年3月13日在16:06

#4 楼


如果您通过添加status-review标签来升级问题,但有某种原因导致该问题“得到解决” –也许社区中的某人实际上可以回答该问题。也许错误确实是用户方面的问题;等等。请在教师休息室中对CM进行解释,以说明情况。


处理此类情况的本能是简单地删除状态审核标签。那还不够吗?与内部跟踪系统的通信是否仅是单向的,以至于添加标签会将问题添加到跟踪器,但是如果没有人工干预,删除标签将不会删除问题?


确实需要对CM进行ping操作吗?


为了防止主持人使用标志过载,请避免进行标志狂欢。


感谢您明确指出。这是我最初向私人渠道主持人提出的系统最大的担忧。作为网站的主持人,这仍然是我最大的担忧,该网站的关联Meta本身比网络中的任何其他网站都要大,而且活跃得多。 GIF是我们在美好的一天的样子(请注意,头部通常会停留在水面之上)。我真的不希望在大量积压的被忽视请求(有人希望CM跟进)上被成千上万的标志淹没。有很多人。

评论


删除标签不会更改我们内部跟踪器中的信息,因此我们无法准确计数仍需注意的问题。

–Catija♦
20 Mar 13 '20 at 2:50

@Catija:是的,我想了很多:ping更是告诉CM“您可以从队列中删除它”,而不是与获得删除标签(或其他任何内容)的许可有关。

– V2Blast
20-3-13的3:26

我仍然担心这种举动疯狂。虽然可以阻止1位用户每天举起2面旗帜,但是如何阻止100位用户每天举起2面旗帜?如果这些碰巧恰好是相同2个帖子的100倍,这没什么大问题,但是我们都知道那不是那样。

–桅杆
20 Mar 13 '20在7:26

坦白说,主持人超载的可能性对我来说也是一个问题:CM将在SO mod聊天室中,因此,如果水开始危险地流到脖子上方,我们可以保持不断的联系并为所有人提供帮助。让我们保持通讯线路畅通,并尝试根据情况进行调整:)

– JNat♦
20-3-13在11:25